Subject: proposed edit (Re: OpenPGP WG meeting minutes)
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 30 Jan 1998 00:53:36 GMT

Ian Brown <[email-masked]> writes:
> > Without stating anything, the critical bit would wreck the signatures on
> > all keys using this feature.  Something more than "reserved for future
> > use" needs to be said.  I'd prefer, "  The critical bit may be safely
> > ignored for this field"..
> 
> Sounds good to me.

Same here.  In fact I think Ryan Anderson's suggest an improvement
over the previous consensus of "reserve for future use", so now we
have: "reserve for future use; criticality bit does not apply for this
field".

So where are we at here, we have 3 or 4 list members saying that this
is their preferred semantics for this section, plus many saying the
same thing in the discussion last year.  Any naysayers?

Otherwise would the active editor of said document be interested to
amend the document appropriately and post the suggested ammendment for
approval.

Would it help if some one wrote a few sentences of specific wording to
put in there?

Thanks,

Adam

To: Ryan Anderson <[email-masked]>
cc: OpenPGP mailing list <[email-masked]>
Subject: Re: OpenPGP WG meeting minutes
Date: Tue, 27 Jan 1998 19:57:39 +0000
From: Ian BROWN <[email-masked]>
Sender: [email-masked]

> Without stating anything, the critical bit would wreck the signatures on
> all keys using this feature.  Something more than "reserved for future
> use" needs to be said.  I'd prefer, "  The critical bit may be safely
> ignored for this field"..

Sounds good to me.

Ian.

Date: Tue, 27 Jan 1998 13:53:07 -0500 (EST)
From: Ryan Anderson <[email-masked]>
To: Ian Brown <[email-masked]>
cc: Bill Stewart <[email-masked]>, OpenPGP mailing list <[email-masked]>
Subject: Re: OpenPGP WG meeting minutes
Sender: [email-masked]

On Mon, 26 Jan 1998, Ian Brown wrote:

> > The ARR stuff was explicitly designed so that implementations that didn't
> > want to implement it could ignore it safely; it's hard to undo that.
> > Leave it alone for the standard
> 
> That's all I'm asking, and seemed to be the consensus of the group -
> document subpacket 10 as "reserved for future use" with no other
> comment. This did not seem to be what Jon Callas decided at the IETF
> meeting.
> 

Withoutt stating anything, tge critical bit would wreck the signatures on
all keys using this feature.  Something more than "reserved for future
use" needs to be said.  I'd prefer, "  The critical bit may be safely
ignored for this field"..

Ryan anderson
PGP fp: 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Formal Draft
Date: 27 Jan 1998 18:07:48 GMT
Organization: IKS GmbH Jena
Lines: 8
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

As discussed with John, I'm working on a formal specification of the OpenPGP
message format. At the moment it's a machine readable syntax and partially
semantics definition. This specification should be as small as possible and
should be a slow (sic!) reference implementation.

ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/pgp/OpenPGP/
  draft-ietf-openpgp-formal-YYYY-MM-DD.tgz  - current snapshot
  draft-ietf-openpgp-formal.changes         - timeline & history

Date: Mon, 26 Jan 1998 10:57:46 -0800
To: Carl Ellison <[email-masked]>
From: Vinnie Moscaritolo <[email-masked]>
Subject: Re: SPKI in OpenPGP format
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I am going to try to answer a number of comments from Carl an Bill here.

let me summerize my question, I belive that a  SPKI cert can be represented
by using an OpenPGP standalone sig with the follwoing form:

VALIDITY - represented by the signature creation/expiration fields
ISSUER   - represented by the Key ID field.
SUBJECT		- notation value/data pair (SPKI_SUBJ)
AUTHORIZATION	- notation value/data pair  (SPKI_AUTH)
DELEGATION 	- notation value/data pair  (SPKI_DELEG)

The notation  records are a type/value  structure that could contain a SPKI
statement.

It could be as simple as having a type 'SPKI' followed by an encapsulated
SPKI record  or as above I am  shifting the  Validity and Issuer fields  to
the standard standalone sig fields.

An  OpenPGP parser doesnt have to understand the notation data, it can just
check that the signature and validity dates work and pass up the notation
data to it's client for further processing.

But I am not asking to extend the the OpenPGP standard in any way, the
notation fields are already there and there is nothing  in the proposed
standard that enforces how a notation is used.

 This doesnt really break either of the standards, its just a way to
encapulate a SPKI statement into an OPenPGP form,

>	What features of SPKI do you believe PGP could benefit from?

I am trying to build a Public Key authorized User auth module for managing
file system access.

>	Can we translate from PGP to SPKI canonical format easily?

absolutely. and that might be the key here, there is nothing that prevents
the data from being translated from one form to another. The above form
simply lets allows the SPKI information to be carried in an openPGP packet.

One question though, judging from my responses I think I might have
misunderstood the Subject field. I was suggest that subject also be a
Notation value/data pair that contained the keyID or maybe
fingerprint/alg/keyID of the subject..

The current keyservers out there don't index on fingerprints, just keyIDs..
this is a problem that OpenPGP 2 needs to solve, they need to extend the
keyID to a long enough field that it canbe replaced with a fingerprint.

 I was using the key ID to do a lookup, then comparing the fingerprints and
algorithms to ensure I was using the right one. this might be more of an
implementation issue.

__________________________________________________________________________
Vinnie Moscaritolo			    <[email-masked]>
Chief Consulting Engineer
Total Network Security                 	    555 Twin Dolphin Drive
Network Associates, Inc.                    Suite 570
415.572.0430	                            Redwood Shores, CA 94065
Fingerprints: DE60 DB68 8E17 2A3F 60AE A933 88F1 F50E 070A 5CFF (DSS)

1 if by land, 2 if by sea.
	 Paul Revere - encryption 1775
__________________________________________________________________________

Date: Mon, 26 Jan 1998 10:26:23 -0800
To: "William Allen Simpson" <[email-masked]>
From: Vinnie Moscaritolo <[email-masked]>
Subject: Re: SPKI in OpenPGP format
Cc: [email-masked]
Sender: [email-masked]

On 1/25/98, men from black helicopters forced William Allen Simpson to write:

>Vinnie, I had already posted a combined format many months ago to these
>lists.  I called it "Pretty Simple PKI".  Maybe I should post the draft
>again.
>

please send me a copy, I must have missed it.

__________________________________________________________________________
Vinnie Moscaritolo			    <[email-masked]>
Chief Consulting Engineer
Total Network Security                 	    555 Twin Dolphin Drive
Network Associates, Inc.                    Suite 570
415.572.0430	                            Redwood Shores, CA 94065
Fingerprints: DE60 DB68 8E17 2A3F 60AE A933 88F1 F50E 070A 5CFF (DSS)

1 if by land, 2 if by sea.
	 Paul Revere - encryption 1775
__________________________________________________________________________

Date: Mon, 26 Jan 1998 12:21:43 -0500
To: [email-masked], [email-masked], [email-masked]
From: Robert Guerra <[email-masked]>
Subject: April 23-24:PGP Keysigning session..can one be arranged?
Cc: [email-masked]
Sender: [email-masked]

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

Content-Transfer-Encoding: quoted-printable

I would like to know if it would be possible to arrange a PGP
keysigning session among those who will be in Toronto for the below
mentioned conference. No doubt it is an opportunity to have people
from "out of town" participate, and hence increase the parties
participating in the keysigning session.

comments/suggestions most welcome.

regards

robert

- -- conference details below --

=46rom: Karen Brown <[email-masked]>
Newsgroups: comp.security
Subject: ELLIPTIC CURVE CRYPTOGRAPHY (ECC) SEMINAR - April 23-24, 1998
Date: Fri, 23 Jan 1998 10:34:00 -0800

ELLIPTIC CURVE CRYPTOGRAPHY (ECC) SEMINAR

An Advanced Seminar On Elliptic Curve Cryptography and the Ideal Way to
Learn the Techniques of Elliptic Curve Cryptography

Lead by:
Dr. Scott Vanstone
Renowned ECC Pioneer and Certicom Co-Founder and Chief Cryptographer

April 23 and 24, 1998 (following the Certicom PKS '98 Conference) - Four
Seasons Hotel, Toronto, Canada

The Elliptic Curve Cryptography (ECC) Seminar offers a comprehensive
overview of ECC and is lead by Dr. Vanstone, one of the world's leading
cryptographers.  This seminar is a convenient intensive introduction to
the algorithms and implementation techniques of ECC.

The ECC Seminar Includes:
=B7 an overview of relevant abstract algebra
=B7 motivation for and construction of the group of points formed from
an   elliptic curve over a finite field
=B7 implementation issues for both hardware and software
=B7 security issues of the ECDLP (Elliptic Curve Discrete Logarithm
Problem)
=B7 an overview of protocols using ECC for signature/verification, key
agreement, key transport, and encryption/decryption
=B7 representations, point compression, security considerations, and
other   issues affecting implementations of ECC in both hardware and
software

At the end of the seminar, you will understand how to:
=B7 formulate an elliptic curve group
=B7 construct a public-key cryptosystem from this group
=B7 evaluate the difficulty of the Elliptic Curve Discrete Logarithm
Problem (ECDLP) on which the security of ECC is based
=B7 efficiently implement ECC in both hardware and software

Course prerequisites:
=B7 an understanding of abstract algebra
=B7 a general knowledge of public-key cryptosystems
=B7 a degree in Mathematics, Engineering or Computer Science.

=46or more information and or register, visit the Certicom PKS website or
contact Certicom
www.certicom.com/pks
[email-masked]
905-501-3836 (Canada)
650-312-7977 (USA)

Robert Guerra - PGP public key available on PGP key servers
Email-> mailto:[email-masked]
Home Page-> http://www.geocities.com/CapitolHill/3378

Date: Mon, 26 Jan 1998 10:56:29 +0000
From: Ian Brown <[email-masked]>
To: Bill Stewart <[email-masked]>
CC: OpenPGP mailing list <[email-masked]>
Subject: Re: OpenPGP WG meeting minutes
Sender: [email-masked]

> The ARR stuff was explicitly designed so that implementations that didn't
> want to implement it could ignore it safely; it's hard to undo that.
> Leave it alone for the standard

That's all I'm asking, and seemed to be the consensus of the group -
document subpacket 10 as "reserved for future use" with no other
comment. This did not seem to be what Jon Callas decided at the IETF
meeting.

As Ian Grigg said, documenting the Additional Receipient Request in a
neutral way is impossible with the conflicting variety of opinions in
this group. The only fair way to deal with it is to not mention it at
all.

Ian.

Date: Sun, 25 Jan 1998 16:47:13 -0700
To: Ian BROWN <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: OpenPGP WG meeting minutes
Cc: OpenPGP mailing list <[email-masked]>
Sender: [email-masked]

At 02:51 PM 1/25/98 +0000, Ian BROWN wrote:
>> ARR subpacket - This will be defined as optional.
>> The draft will say explicitly that the implementation
>> can do anything it wants with this. It does not
>> have to use it.
>
>I was surprised, to say the least, to see this in the minutes of the December 
>meeting. In the weeks running up to the standard, extensive discussion over 
>this topic occurred. An almost complete consensus formed around the view that 
>subpacket 10 should be "reserved for future/PGP use" with no other comment. 
>This is a compromise solution that allows PGP Inc. to persue their message 
>recovery scheme while retaining compatibility with other implementations that 
>do not.
>
>As Ian Grigg said, there is certainly no consensus within the WG that this 
>feature should be included. It should therefore not be "blessed" by 
>documentation within the standard.

Fundamentally, your choices are to 
- leave the structure that way (either documenting it or not), or 
- define some alternate required behaviour for #10, like reject the key
	(which is identical to the behaviour with the critical bit set :-)
	or display an error message or mail the ARR key to aclu.org, or
- replace the while subpacket structure with something completely
	different, forcing PGP to be non-compliant and to use some other
	extension mechanism for the evil option.  (Basically unacceptable.)
The ARR stuff was explicitly designed so that implementations that didn't
want to implement it could ignore it safely; it's hard to undo that.
Leave it alone for the standard, or perhaps also define a SHOULD
error message for unsupported subpacket types.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

To: "John W. Noerenberg" <[email-masked]>
cc: OpenPGP mailing list <[email-masked]>
Subject: Re: OpenPGP WG meeting minutes
Date: Sun, 25 Jan 1998 14:51:14 +0000
From: Ian BROWN <[email-masked]>
Sender: [email-masked]

> ARR subpacket - This will be defined as optional.
> The draft will say explicitly that the implementation
> can do anything it wants with this. It does not
> have to use it.

I was surprised, to say the least, to see this in the minutes of the December 
meeting. In the weeks running up to the standard, extensive discussion over 
this topic occurred. An almost complete consensus formed around the view that 
subpacket 10 should be "reserved for future/PGP use" with no other comment. 
This is a compromise solution that allows PGP Inc. to persue their message 
recovery scheme while retaining compatibility with other implementations that 
do not.

As Ian Grigg said, there is certainly no consensus within the WG that this 
feature should be included. It should therefore not be "blessed" by 
documentation within the standard.

The IETF Working Group Guidlines (RFC 1603) say that:

> decisions reached during IETF meetings are NOT final, but must be
> conveyed to the mailing list to verify WG consensus.

I think this issue is far from closed.

Ian.

Date: Sun, 25 Jan 98 14:09:04 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: SPKI in OpenPGP format
Sender: [email-masked]

Vinnie, I had already posted a combined format many months ago to these
lists.  I called it "Pretty Simple PKI".  Maybe I should post the draft
again.

The PGP key itself serves as the subject.  And I used the old literal to
end of packet (no length) to serve as the "()" element grouping.  The
current name element is simply interpreted to be tag "(name <foo>)".

This construct would allow extension of current PGP so that you could
sign 2 or more user names in a group at once, rather than the current
one at a time limitation, and incorporate SDSI names to be signed.

It should be easy to modify the current libraries to interpret the
elements, and translate between them, without any confusion with older
PGP formats (they would stop on the literal).  I checked the sources,
everything looked OK.

I could not get agreement on the SPKI list that a binary form would be
the canonical form (very important for signing), and the textual form
would merely be a visual translation for human editting programs.  A lot
of us have desired this, but no overwhelming consensus was achieved
(not enough to get Ellison to change).

Also, key lengths would need to be bit-length instead of byte-length
(very important for backward PGP element compatibility).  Ellison
adamantly refused this point.

On the OpenPGP side, there seemed to be general agreement that the PGP 5
draft formats needed to be finished before worrying about extensions.

So, yes, it could be done easily and elegantly, but the parties lack the
political will.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Date: Sat, 24 Jan 1998 21:20:56 -0500
To: Vinnie Moscaritolo <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: SPKI in OpenPGP format
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

At 03:13 PM 1/23/98 -0800, Vinnie Moscaritolo wrote:
>Here is a possible way to represent a SPKI certifcate in OpenPGP format
>OpenPGP added a utility field called a notation that could be used
>to hold SPKI strings. Its more of a binary (un human readble version)
>but it does maintain the spirit of SPKI.

Vinnie,

	I think I understand what you're trying here, but I wonder if you want to 
introduce all the complexity of SPKI in your format.

	For example, if I were to be designing this, I wouldn't create an SPKI 
SUBJECT field.  The subject can be the key to which this information is 
attached.  [Of course, I'm assuming that there would be normal SPKI certs 
living outside the structure.  If you're not assuming that, then I need to 
think some more.]

	To me, PGP suffers mostly from the lack of SDSI names.  I don't see PGP 
used to do general purpose access control -- the task for which SPKI's auth 
fields were created.

	So, the subset I would concentrate on in PGP is SDSI names.  Doing that 
requires some design work at the user interface level, rather than just in 
data structures.

	What features of SPKI do you believe PGP could benefit from?

	Can we translate from PGP to SPKI canonical format easily?

	Do we need to express everything SPKI can in the PGP format?

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison  [email-masked]   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+

Date: Sat, 24 Jan 1998 14:06:22 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Possible Error/Oversight in Encrypted Session Key Pkt format
Sender: [email-masked]

Lindsay Mathieson, <[email-masked]>, writes:
> For Encrypted Session Key Packets (Section 5.1) the OpenPGP spec states:
>
> The encrypted value "m" in the above formulas is derived from the
> session key as follows.  First the session key is prepended with a
> one-octet algorithm identifier that specifies the conventional
> encryption algorithm used to encrypt the following Symmetrically
> Encrypted Data Packet.  *Then a two-octet checksum is appended which is
> equal to the sum of the preceding octets, including the algorithm
> identifier and session key, modulo 65536.*
>
> The problem is with the checksum, the spec states that it includes the
> algorithm identifier, whereas in PGP 2.x it actually doesn't, it only
> includes the session key itself. I'm not sure is this is the case for PGP
> 5.x though. Also it might be handy to mention that the checksum is in MSB
> ordering.
>
> So perhaps if it was changed to:
>
> Then a two-octet checksum in MSB order is appended, which is
> equal to the sum of the preceding session key octets, modulo 65536.

You are correct, I misread the code when I provided this information to
Jon.  The alg ID is not included in the checksum in 5.X or in 2.X.  We
should correct the draft spec.

Hal Finney
[email-masked]
[email-masked]

Date: 25 Jan 1998 14:43:34 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Possible Error/Oversight in Encrypted Session Key Pkt format
To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

For Encrypted Session Key Packets (Section 5.1) the OpenPGP spec states:

The encrypted value "m" in the above formulas is derived from the
session key as follows.  First the session key is prepended with a
one-octet algorithm identifier that specifies the conventional
encryption algorithm used to encrypt the following Symmetrically
Encrypted Data Packet.  *Then a two-octet checksum is appended which is
equal to the sum of the preceding octets, including the algorithm
identifier and session key, modulo 65536.*

The problem is with the checksum, the spec states that it includes the
algorithm identifier, whereas in PGP 2.x it actually doesn't, it only
includes the session key itself. I'm not sure is this is the case for PGP
5.x though. Also it might be handy to mention that the checksum is in MSB
ordering.

So perhaps if it was changed to:

Then a two-octet checksum in MSB order is appended, which is
equal to the sum of the preceding session key octets, modulo 65536.

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.7, on January 25, 1998, in Win95 4.0
	http://www.blackpaw.com/

From: [email-masked]
DATE: 23 Jan 98 12:21:21 AM
TO: [email-masked]
SUBJECT: Are You Happy!
Sender: [email-masked]

There is brilliant information available to you,  
that will enable you to fully understand yourself 
and everybody else. This knowledge can benefit
you tremendously in many ways.

It can help you to get the very best out of your 
career, or discover your most suitable new career, 
and of course being happy at work, really
improves the finances.
 
It can also really enhance your love life. If you're 
in a relationship, it works great, because you are 
able to fully understand your own and your partner's 
emotions and motivations. If you're not, you will know 
exactly what you want from your perfect mate and what 
they will find attractive about you. 

Another big advantage to becoming balanced and happy 
is that good health runs hand in hand.

Take a closer look two free pages of information at:
http://www.po9.com

Date: Fri, 23 Jan 1998 15:13:33 -0800
To: [email-masked], [email-masked]
From: Vinnie Moscaritolo <[email-masked]>
Subject: SPKI in OpenPGP format
Sender: [email-masked]

Here is a possible way to represent a SPKI certifcate in OpenPGP format
OpenPGP added a utility field called a notation that could be used
to hold SPKI strings. Its more of a binary (un human readble version)
but it does maintain the spirit of SPKI.

the packet format is further descreibed in sect 5.2.2. of the openPGP spec.

just a thought.

SPKI packet represented in OpenPGP Standalone signature packet

        size    hex-value       desc

Packet Header
-------------
        1       8B           Ptag       10  0010 11
                                     |   |    '--  3  = indeterminate  len
                                     |   '-------- 2 = Signature Packet
                                     '------------  old packet format
Version 4 Signature packet

        1       04           version number:  (4).
        1       02           Signature Types: Standalone signature
        1       XX           public key algorithm. ( DSA = 0x11 )
        1       XX           hash algorithm        ( SHA1 = 0x02 )

Hashed SubPacket Data
        2       XXXX         Hashed subpacket len
 ---
-------------
        1       02              2 = signature creation time         VALIDITY
        4       XX XX XX XX     Signature creation time
 ---
        1       03              3 = signature expiration time
        4       XX XX XX XX     Signature creation time
 ---
-------------
        1       10              16 = issuer key ID                  ISSUER
        8       XX...           Key ID of issuer
 ---
-------------
        1       14              20 = notation data
AUTHORIZATION
        4       0000 0000       (4 octets of flags)
        2       0009                - name length
        2       XXXX                - value length,
        9       'SPKI_AUTH'     - name data
        N       XX....              - value data
 ---
-------------
        1       14              20 = notation data                  SUBJECT
        4       0000 0000       (4 octets of flags)
        2       000C                - name length
        2       0008                - value length,
        8       'SPKI_SUBJECT'      - name data
        N       XX....              - Key ID of subject
 ---
-------------
        1       14              20 = notation data                  DELEGATION
        4       0000 0000       (4 octets of flags)
        2       000A                - name length
        2       0000                - value length          the existance
of this field means
        10      'SPKI_DELEG'        - name data             that the
subject may delagate the priv
  ---
UnHashed SubPacket Data
        2       00 00        UnHashed subpacket len (not used)
Signature Data
        2       XXXX        - Two-octet field holding left 16 bits of
signed hash value.
        N       XXXX...     - One or more multi-precision integers
comprising the signature.

__________________________________________________________________________
Vinnie Moscaritolo			    <[email-masked]>
Chief Consulting Engineer
Total Network Security                 	    555 Twin Dolphin Drive
Network Associates, Inc.                    Suite 570
415.572.0430	                            Redwood Shores, CA 94065
Fingerprints: DE60 DB68 8E17 2A3F 60AE A933 88F1 F50E 070A 5CFF (DSS)

1 if by land, 2 if by sea.
	 Paul Revere - encryption 1775
__________________________________________________________________________

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: proposed FP sig subpacket type
Date: 23 Jan 1998 15:58:51 GMT
Organization: IKS GmbH Jena
Lines: 19
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Vinnie Moscaritolo wrote:
>I would like to suggest that a Issuer Key Fingerprint be added to the
>acceptable  Signature Subpacket types (sec 5.2.2.2).   I suspect that this
>fingerprint should be an MPI since its a hash of the Issuer Signing key

Yes, there is a field for this purpose.

>From the OpenPGP Reference implementation to be:
sigsub_keyid:
        lex_token '\x10' keyid
;

No, it's not a MPI.
keyid: 
        {lex_octets(8)} octets {memcpy($$, $2.field, 8); free($2.field)}
;

PS: Yes, I talked to John before. There will be a formal specification, too.
    (make draft at my system...) It will be GPLed.

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 23 Jan 98 09:29:28 -0500
To: [email-masked]
Subject: Please Fix
Sender: [email-masked]

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

Could someone please fix this as I receive a bounce from PGP Inc. every
time I post to the list:

>Thank you for your email.  The requested user now receives mail at
>[email-masked]
>
>For PGP-related issues, email [email-masked].
>
>Thanks.
>
>Pretty Good Privacy, Inc.
>http://www.pgp.com

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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows?  WINDOWS?!?  Hahahahahehehehehohohoho...

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 23 Jan 98 08:58:11 -0500
To: Bill Stewart <[email-masked]>
Cc: [email-masked] (Hiroyuki Yamada), [email-masked]
Subject: Re: The canonical <CR><LF> in rfc2015
Sender: [email-masked]

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

In <[email-masked]>, on 01/23/98 
   at 03:21 AM, Bill Stewart <[email-masked]> said:

>At 02:46 PM 1/23/98 +0900, Hiroyuki Yamada wrote:
>>I have a question about PGP signed data in section 5-(1)(2)(3)
>>of rfc2015. It requires <CR><LF> for end of each lines instead
>>of <NL>.  Could anybody have any reason for it ?

>Different operating systems have different conventions for
>representing the end of a line.  Unix uses <LF> ( = <NL> ).
>MS-DOS uses <CR><LF> as do some other systems.  I think
>Macintoshes may use <CR>.  So if you want to sign a document on one
>system and verify the signature on the other,
>you have to know which convention is being used,
>or hope that the your operating system, the signer's operating system, or
>some glue in between did not change the newline.
>If you always sign the same version, this doesn't happen,
>and <CR><LF> probably will not do Bad Things on most systems.

Isn't <CR><LF> pretty much the standard in the RFC's ? IIRC RFC733 onward
all specify <CR><LF>. Since RFC733 and for the most part RFC822 pre-date
the PC revolution I would imagine that this was the standard convention
for the machines being used by ARPANET at the time (I was still using an
IBM1130 then and I don't remember what it used).

Perhaps a Net historian could step in and clarify the matter.

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: This is a TAG-O-Matic
             Multi-line Sample
             Tag 

Date: Fri, 23 Jan 1998 00:21:25 -0800
To: [email-masked] (Hiroyuki Yamada), [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: The canonical <CR><LF> in rfc2015  
Sender: [email-masked]

At 02:46 PM 1/23/98 +0900, Hiroyuki Yamada wrote:
>I have a question about PGP signed data in section 5-(1)(2)(3)
>of rfc2015. It requires <CR><LF> for end of each lines instead
>of <NL>.  Could anybody have any reason for it ?

Different operating systems have different conventions for
representing the end of a line.  Unix uses <LF> ( = <NL> ).
MS-DOS uses <CR><LF> as do some other systems.  I think
Macintoshes may use <CR>.  So if you want to sign a document
on one system and verify the signature on the other,
you have to know which convention is being used,
or hope that the your operating system, the signer's operating
system, or some glue in between did not change the newline.
If you always sign the same version, this doesn't happen,
and <CR><LF> probably will not do Bad Things on most systems.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Fri, 23 Jan 1998 14:46:18 +0900
From: [email-masked] (Hiroyuki Yamada)
To: [email-masked]
Subject: The canonical <CR><LF> in rfc2015  
Sender: [email-masked]

I have a question about PGP signed data in section 5-(1)(2)(3)
of rfc2015. It requires <CR><LF> for end of each lines instead
of <NL>.  

Could anybody have any reason for it ?

Thank you,
hiro

Date: Thu, 22 Jan 1998 11:39:55 -0800
To: [email-masked]
From: Vinnie Moscaritolo <[email-masked]>
Subject: proposed FP sig subpacket type
Sender: [email-masked]

I would like to suggest that a Issuer Key Fingerprint be added to the
acceptable  Signature Subpacket types (sec 5.2.2.2).   I suspect that this
fingerprint should be an MPI since its a hash of the Issuer Signing key

While I was  trying to write some code that will build and use standalone
signatures it occured to me that in order to test that a standalone
signature
packet is valid  you either need to compare it against the Issuer's Key
Fingerprint or test the sig against a possible number of keyid matches.

I feel that Issuer Key ID is mostly useful for quick lookup a key, but
offers a higher chance of key collision than a fp would, so that having
both available is useful.

I understand that there is mmotavation to evolve the standard away from 8
octet keyIDs to nbyte key Fp, and this thing is beter addressed in a v2
spec, but this  addition in the v1 spec shouldnt break anything. (I hope)

any comments?

__________________________________________________________________________
Vinnie Moscaritolo	    tel:  415.524.6222      Pretty Good Privacy, Inc.
Chief Consulting Engineer  main: 415.572.0430      2121 S. El Camino Real

<[email-masked]>	    web: http://www.pgp.com San Mateo, CA 94403

DH Key: http://keys.pgp.com:11371/pks/lookup?op=get&search=0x070A5CFF

1 if by land, 2 if by sea.
	 Paul Revere - encryption 1775
__________________________________________________________________________

Date: Tue, 20 Jan 1998 15:09:32 -0500
From: [email-masked]
To: OpenPGP mailing list <[email-masked]>
Subject: Re: OpenPGP WG meeting minutes
Sender: [email-masked]

On Mon, 19 Jan 1998, John  W. Noerenberg wrote:

> Here are the long delayed minutes from the IETF meeting in December.  Tony
> Mione recorded them, and I've annotated them slightly.
> 
> 40th IETF, Washington, DC
> OpenPGP Working Group Meeting Minutes
> 8-Dec-1997

...

> Draft : PGP Message formats (Jon Callas)
> 	Jon discussed the most recent decisions on various open issues
> 		in the PGP Message formats draft
> 		(drafts-ietf-openpgp-formats-00.txt). There was some discussion
> 		on certain points. Some decisions by Jon, et al were reversed
> 		or modified during the discussion.

...

> 	2.5.3.3 Iterated/Salted String-to-key - This is long, hairy and
> 		complicated to implement. We have considered removing it.

The following should do all three variants (0,1,3), but I haven't tested
them all, nor any hashtype not normally used by PGP 5.0b8.  The original
is at www.cryptography.org in cipcop09.tgz in the libraries directory.

bp points to a buffer with the key material starting with the crypto type,
and hashpass contains the user typed in password.

cfbinit sets the key and initial IV for the cfb decryption:

void cfbinit(unsigned char *key, unsigned char *iv0, int cipher);

/*------------------------------------*/
/* string to key and initialize conventional encryption */

void getcfbkey(unsigned char **bp, unsigned char *hashpass)
{
  unsigned int i = 0, j, k = 0, ca, ha, sa;
  unsigned char hbuf[256];
  unsigned char hashctx[1024];

  ca = *(*bp)++;                /* crypto type */
  sa = *(*bp)++;                /* salt type */
  ha = *(*bp)++;                /* hash type */

  if (sa & 1) {
    memcpy(hbuf, *bp, 8);       /* salt */
    memcpy(&hbuf[8], hashpass, strlen(hashpass));
    *bp += 8;
    k = 8 + strlen(hashpass);
    i = k;
  }
  if (sa == 3) {
    i = *(*bp)++;               /* postfix - hash size */
    j = i >> 4;
    i = (i & 15) + 16;
    i <<= j + 6;
  } else if (sa == 0) {         /* salt-free */
    memcpy(hbuf, hashpass, strlen(hashpass));
    i = strlen(hashpass);
    k = i;
  } else if (sa != 1)           /* 1 = just salt, else error */
    exit(-1);

  j = i / k;                    /* loops over whole text */
  i = i % k;                    /* last loop size */

  if (ha < 1 || ha > MAXHASH)
    exit(-1);

  (*hashinit[--ha]) (hashctx);
  while (j--)
    (*hashupdate[ha]) (hashctx, hbuf, k);
  (*hashupdate[ha]) (hashctx, hbuf, i);
  (*hashfinal[ha]) (hbuf, hashctx);
  memcpy(&hbuf[hashlen[ha]], hbuf, hashlen[ha]);
  memcpy(&hbuf[hashlen[ha] * 2], hbuf, hashlen[ha] * 2);

  cfbinit(hbuf, *bp, ca);
  *bp += 8;
}

> 		The rationale for its use is that:
> 			1-Salt perturbs encryption of strings (same string
> 				encrypts to different values each time it
> 				is used)
> 			2-Iteration adds compute time for the craker program
> 				running a dictionary attack.
> 			We've seen 3 options mentioned
> 				1) Remove it
> 				2) Change 8-bit float to 32 bit int
> 				3) Change it to a MAY
> 			Request for comments from WG
> 
> 		Comments from WG member: Options add complexity but is useful
> 			and important. The member would not have a problem
> 			with it if the float was changed to a 32-bit
> integer (2).

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

To: "William H. Geiger III" <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: MISTY1
Date: Wed, 21 Jan 1998 04:15:13 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

>>>>> "W" == William H Geiger <[email-masked]> writes:
 W> Anyone unfamiliar with Misty should look at the CP archives for
 W> the numerous posts by Nobuki Nakatuji. It has snake-oil written
 W> all over it.  This is exactly what is meant by 'pet' algorithm.

I read some emails 'about MISTY encryption Algorithm' from CP
archives.  Do you mention about MISTY1 has kept secret key while
encrypting?

My opinions are below.

1) Design of MISTY1 assume that a secret key is a session key which
will be disposed and never use it again.

2) lots of cipher program, included PGP, can't avoid "CORE DUMP
ATTACK"( core-dumped running process and do "gdb core"). Because
expansion key is fixed while encrypting.

3) MISTY1 is fast and is proved a strong cipher against DC, LC.

I mention about Nobuki Nakatuji. I've never heard his name until 18
hours ago.  Today, Nobuki e-mailed me and said "You need a permission
from MITI to open your MISTY1 code on your website, don't you?".

Nobuki seems he don't know about cryptography situation in Japan.

Fortunately, In Japan, programs for research or programs with known
technology are NOT required any permission from MITI. This export
condition is described in document which was issued from MITI export
department. So, there are many PGP program archive sites in Japan and
you can get it.

Most of Japanese cryptographers and real hackers who have made
so-high-tech programs, know about it because they're must write their
academic paper, AI or high-tech programs and do something like to
issue Internet Draft written by Matsui-san.

But Nobuki don't know about it.

MISTY's references are here.

   [1]  M. Matsui, "New Block Encryption Algorithm MISTY", Fast Software
        Encryption - 4th International Workshop (FSE'97), LNCS 1267,
        Springer Verlag, 1997, pp.54-68

   [2]  K. Nyberg and L.R. Knudsen, "Provable Security Against a
        Differential Attack", Journal of Cryptology, Vol.8, No.1, 1995,
        pp. 27-37

   [3]  K. Nyberg, "Linear Approximation of Block Ciphers", Advances in
        Cryptology - Eurocrypt'94, LNCS 950, Springer Verlag, 1995,
        pp.439-444

   [4]  M. Matsui, "New Structure of Block Ciphers with Provable
        Security Against Differential and Linear Cryptanalysis", Fast
        Software Encryption - Third International Workshop, LNCS 1039,
        Springer Verlag, 1996, pp.205-218

-- 
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
URL://www.pp.iij4u.or.jp/~h2np

Date: Tue, 20 Jan 1998 10:16:19 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: OpenPGP WG meeting minutes
Cc: [email-masked]
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> Anyone unfamiliar with Misty should look at the CP archives for the
> numerous posts by Nobuki Nakatuji. It has snake-oil written all over it.
> This is exactly what is meant by 'pet' algorithm.

Misty is described in the proceedings of the most recent annual conference
on fast encryption algorithms.  It is designed to be provably resistant
to linear and differential cryptanalysis.  As a new set of algorithms
(a few variants exist under the "Misty" label), it is one of many where
a "wait and see" attitude is appropriate to see how it holds up.  As a
patented algorithm, it may have trouble competing with alternatives that
are free of restrictions.

However your charge that it is "snake-oil" seems unfounded.  It appears
to be a respectable academic development effort, within the mainstream of
cryptographic research, and has some reasonable-looking theory behind it.
As far as I know there has been no cryptanalysis or technical commentary
of any sort regarding Misty on the cypherpunks mailing list.

Hal Finney
[email-masked]
[email-masked]

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 20 Jan 98 11:32:57 -0500
To: Hironobu Suzuki <[email-masked]>
Cc: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller), [email-masked]?=
Subject: Re: OpenPGP WG meeting minutes
Sender: [email-masked]

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

In <[email-masked]>, on 01/20/98 
   at 09:48 AM, Hironobu Suzuki <[email-masked]> said:

>>>>>> "Ulf" == Ulf =?iso-8859-1?Q?M=F6ller?= <[email-masked]> writes:
> >> But I want new algorithm id for MISTY1 when this document become
> >> RFCXXXX. MISTY1 which was designed by Matsui-san looks so good.  I
> >> believe an algorithm which is described in RFC is not a `pet' one.

> Ulf> This algorithm is not any useful in the context of OpenPGP
> Ulf> because it is patented and is freely available only for academic
> Ulf> use.

>That's right.

>I realize that "FREELY AVAILABLE ONLY FOR ACADEMIC" is the biggest
>obstacle to become MISTY1 draft to RFC. I think ( and hope ) when MISTY1
>draft goes to RFC, MISTY1 will be royalty-free algorithm as well as
>CAST128.  If MISTY1 can't become royalty-free, MISTY1 draft maybe reject.

Anyone unfamiliar with Misty should look at the CP archives for the
numerous posts by Nobuki Nakatuji. It has snake-oil written all over it.
This is exactly what is meant by 'pet' algorithm.

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows is to OS/2 what Etch-a-Sketch is to art.

To: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Cc: [email-masked]
Subject: Re: OpenPGP WG meeting minutes 
Date: Tue, 20 Jan 1998 23:48:48 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

>>>>> "Ulf" == Ulf =?iso-8859-1?Q?M=F6ller?= <[email-masked]> writes:
 >> But I want new algorithm id for MISTY1 when this document become
 >> RFCXXXX. MISTY1 which was designed by Matsui-san looks so good.  I
 >> believe an algorithm which is described in RFC is not a `pet' one.

 Ulf> This algorithm is not any useful in the context of OpenPGP
 Ulf> because it is patented and is freely available only for academic
 Ulf> use.

That's right.

I realize that "FREELY AVAILABLE ONLY FOR ACADEMIC" is the biggest
obstacle to become MISTY1 draft to RFC. I think ( and hope ) when
MISTY1 draft goes to RFC, MISTY1 will be royalty-free algorithm as
well as CAST128.  If MISTY1 can't become royalty-free, MISTY1 draft
maybe reject.

					--hironobu

PS. 

I already e-mailed to Matsui-san and Ohta-san about algorithms in RFC
should be free from royalty.

Subject: Re: OpenPGP WG meeting minutes
To: [email-masked] (Hironobu Suzuki)
Date: Tue, 20 Jan 1998 14:05:14 +0100 (NFT)
Cc: [email-masked]
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Sender: [email-masked]

> But I want new algorithm id for MISTY1 when this document become
> RFCXXXX. MISTY1 which was designed by Matsui-san looks so good.  I
> believe an algorithm which is described in RFC is not a `pet' one.

This algorithm is not any useful in the context of OpenPGP because
it is patented and is freely available only for academic use.

To: [email-masked]
Subject: Re: OpenPGP WG meeting minutes
Date: Tue, 20 Jan 1998 11:50:17 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

> Miscellaneous: (Comments not recorded)
...
>		We should not just put in everyone's pet algorithms.

I agree.

But I want new algorithm id for MISTY1 when this document become
RFCXXXX. MISTY1 which was designed by Matsui-san looks so good.  I
believe an algorithm which is described in RFC is not a `pet' one.

----MISTY1 INTERNET DRAFT----
INTERNET-DRAFT                                                   H. Ohta
Expires in six months                                          M. Matsui
                                         Mitsubishi Electric Corporation
                                                           December 1997

            A Description of the MISTY1 Encryption Algorithm

                     <draft-ohta-misty1desc-00.txt>

---
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
URL://www.pp.iij4u.or.jp/~h2np

Date: 20 Jan 1998 23:25:57 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: OpenPGP WG meeting minutes
To: "John  W. Noerenberg" <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>o Develop a protocol based on RFC 1873, RFC 2015 and PGP to
>		  encrypt and sign email.

Do you mean RFC 1847 rather than 1873 ?
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.6.1.8, on January 20, 1998, in Win95 4.0
	http://www.blackpaw.com/

Date: Mon, 19 Jan 1998 13:03:38 -0800
To: [email-masked], OpenPGP mailing list <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: OpenPGP WG meeting minutes
Cc: Tony Mione <[email-masked]>
Sender: [email-masked]

Here are the long delayed minutes from the IETF meeting in December.  Tony
Mione recorded them, and I've annotated them slightly.

40th IETF, Washington, DC
OpenPGP Working Group Meeting Minutes
8-Dec-1997

Antonino N. Mione

John Norenberg made openning comments and reviewed the agenda
for the meeting.

OpenPGP Meeting Agenda

	WG Goals (John Norenberg)
	Phil Zimmerman (Comments)
	Draft : PGP Message formats (Jon Callas)
	2015 OP/MIME
	Trust model documents (John Norenberg)
	Additional topics or other business?

WG Goals (John Norenberg)
	John read the Working Group Charter in order to review the
		goals of the group.

		John's comments: The goal of the OpenPGP group is to do two
things.
		o Develop a cryptographic exchange protocol based on PGP
packets.
		o Develop a protocol based on RFC 1873, RFC 2015 and PGP to
		  encrypt and sign email.

Phil Zimmerman (Comments)
	Phil Zimmerman was asked to make comments on PGP and the
		IETF working group.

	Phil's comments mainly revolved around his original design
		goals. He has resisted throwing in just "any"
		proposed block cipher. He is also trying to preserve
		the "Grass roots" architecture of the original PGP
		implementation.

	Question from WG attendee: Has X.509 compatibility been considered?
	Phil: I would like to avoid it. It is bloated & expensive to
		implement. However, we would like to peacefully coexist with
		this technology and provide users an upgrade path from X.509
		to OpenPGP.

	Question from WG attendee: Did you mean this for the OpenPGP
		standard or just for PGP Inc.?
	Phil: That is up to this Working group

	Question from WG attendee: Are you also designing a PKI and SPKI?
	John N.: We are dnt defining an infrastructure. Just how keys work.
		There will have to be continual heavy pressure from
		outside the working group in order for us to take that on.

	John N(Additional comments): A 'standard' must be well defined
		and widely deployed in order to be useful. Our goal
		is to have a standard for cryptographic message exchange.

Draft : PGP Message formats (Jon Callas)
	Jon discussed the most recent decisions on various open issues
		in the PGP Message formats draft
		(drafts-ietf-openpgp-formats-00.txt). There was some discussion
		on certain points. Some decisions by Jon, et al were reversed
		or modified during the discussion.

	2.4 Armor - This needs to be moved to a separate chapter.
		Chapter 2 will say that implementations SHOULD support ARMOR.
	Armor headers - We need to have a table of these. We also need to
		flesh out generation of the message ids for multi-part
messages.
	2.6 Cleartext signatures - We are removing this
	x.x Counted strings - This will be removed. The type is not used
		except for one or two places. We will define it in those places
		and declare it as a simple type.
	2.5.3.3 Iterated/Salted String-to-key - This is long, hairy and
		complicated to implement. We have considered removing it.
		The rationale for its use is that:
			1-Salt perturbs encryption of strings (same string
				encrypts to different values each time it
				is used)
			2-Iteration adds compute time for the craker program
				running a dictionary attack.
			We've seen 3 options mentioned
				1) Remove it
				2) Change 8-bit float to 32 bit int
				3) Change it to a MAY
			Request for comments from WG

		Comments from WG member: Options add complexity but is useful
			and important. The member would not have a problem
			with it if the float was changed to a 32-bit
integer (2).
	4.2 Encrypted Session Key - Will be changing the name of this
		to Public Encrypted Session Key to balance naming with
		Conventionally Encrypted Session Key.
	5.3 Signatures
		These will be put in a table and marked as required or optional
		as per comments on the mailing list.
		ISSUER ID subpacket - This will be added to hashed subpackets
		ARR subpacket - This will be defined as optional.
			The draft will say explicitly that the implementation
			can do anything it wants with this. It does not
			have to use it.
		Comments from WG attendee: Agrees with consensus.
			However, would like words to tell implementors what to
			do if they do not want to handle it.
		Jon Callas response: Sounds good.
	Critical flag: This section is confusing. Will rewrite to say that
			if the critical subpacket is not understood by the
			implementation, the signature must be ignored.
		Comment from WG attendee: Criticality must be MUST. This means
			if the implementation does not understand the critical
			subpacket type, it must consider the signature
			invalid.
		Phil: Disagrees. The signature is still valid and should be
			considered such. However, use of any semantic
meaning of
			the signature is lost.
	Preferred key server: Good to have a place to get most recent key.
		Comments from WG attendee: This is starting us down a slippery
			slope.
		John Norenberg: Yes, we have to be careful.  But if we stick to
		defining how to represent keys, and leave the protocols for
infrastructure
		to the infrastrucute folks, we'll be ok.
		Phil: This is good but we need more experience with protocols
			i.e. an implementation that does this.

	Regular expressions: We need a syntax for regular expressions sub
		packet. Requested	pointers to a description of a reg exp
		library to which the draft can refer.
	Negative preferences? (Editor's question) : Did not recieve comments
		saying this was needed. As a result, we will not proceed with
		this.
	UserId revocation subpackets: These will be deferred to v2.
	Other subpacket types (Editor's notes) : Jon had noted some packet
		types that were described (or reserved) in an earlier PGP
		implementation. These were never actually implemented. The
		question was, should we do any of them. Since nobody responded
		that they could not live without these features, they will be
		deferred.
	5.2.2. Signature types
		Identifity : Generic,Personal,Casual,Positive
			Other than Generic, no implementation has generated
				or handled these. As a result there is no
history
				or experience on what the symantics should be.
				Personal, Casual, and Positive will be dropped
				from the document.
		Timestamp signatures
			We shouldn't be taking this on. This is another
			Slippery Slope. We will, however, note that they exist.
		Signatures that bind keys with subkeys
			We have not received a good definition of this.
			If we don't get a solid definition, we will leave
			this out.
	Secret keys
		Encryption is done in PGP's variant of CFB. (Other comments
			not recorded).
	Marker packet
		We will change text so that an implementation can put anything
		it wants into this packet. We will also suggest it
		should contain the impelmentor's name.
	Trust packets
		These will explicitly mark them as implementation-defined.

		Comments from Jeff Shiller(back to marker packet) :
			Can't this be used to leak out data (like the clear
			text message xor'ed with something)? Why have this
			at all. It is a security risk.
		Discussion followed.
		Jon Callas: We will state that it MUST be a constant to
			avoid it being exploited to subvert security.

	Non-text UserIds : These will be deferred. They are not yet defined
		well enough.
		Comments from Phil: These are going to be important.
			We need this in the spec now.
		Discussion followed concerning formatting problems, etc.
		Jon Callas (to Phil): Send a specification to the openpgp list.
	SDSI names : These will be deferred.
		Jon Callas : These are a good thing but we do not have
		enough time.
		Additional comments from Jon: This draft is supposed to go
			to last call sometime in March 98. Ideally, we will
			be AHEAD of that schedule. Jon is hoping to have a new
			draft up shortly, handle additional comments over then
			next month or so (through January) and go to last call
			in February of 98.
	Comment packets : An implementation MAY display a comment but MUST
		NOT interpret contents.
		Jeff Shiller: You may want to reconsider using UTF-8 for
			textbased userid's.
		Jon Callas: This has already been specified in the draft (at
			least, he is pretty sure of this.)
		Chris : Recommends that comments be removed altogether.
		Jeff Shiller: agrees with this.
		Jon Callas: Fine. We will remove them.
	5.n:  Interoperability packets:
		These are desireable, but deferred. The existing definitions
		are insufficient.
	Subkeys (Comments unrecorded)
	7.2 BNF : We need additional BNF for how signatures are formed.
		Comments from WG attendee: Please include at least one example.
		Seconded...
		Jon Callas: Noted...
	Security considerations:
		We will be adding description of stealth-mode and
		packet analysis avoidance.
	Miscellaneous: (Comments not recorded)

		Comments on alogrithm lists from Phil: We have multiple
			algoritms to ensure that if one breaks, users can
contine
			operating securly by just changing preferences.
			We should, however, shoot for minimal # of algoritms.
			We should not just put in everyone's pet algorithms.
		Comment from WG attendee: Other specs give one MUST and
everything
			else MAY. Market should drive the algorithm
selection. We should
			not limit it.
		Phil: Maintained that WE should pick the algorithms.
			Attitude is: "I know cryptography, you don't."
		Perry Metzger: Pick minimum # and types of algoritms for
			interoperability. Let market drive rest.
		Chris?: We should provide a 'private algorithm #' with no
content
			description. This allows others to use OIDs, etc to
			implement anything they want.
		Ned: Agreed. Also, this is not the time to add tons of
algorithms
			to the spec.
		Jon Callas : This is already done. 11 things are reserved for
			private algorithms.

	Algorithms:
		Blowfish
		GOST, needs sboxes specified
			Jon Callas: I can't specify these.
		AES : We have reserved an id
		Ellyptic Curve, IDEA-EDE - added.
	Speculative (stealth mode) keyIDs - Cut's traffic analysis.
	We need to write rationale sections

2015 OP/MIME
	Draft Status
	Technical Changes

Draft status: 80% complete
	www.imc.org/ietf-pgp-mime/mail-archive/0081.html
	New Draft will be in:
		www.imc.org/ietf-open-pgpg/draft-ietf-opengpg-mime-00.txt

	Draft has been submitted to IETF.

Technical changes:
	OP Msg formats now have details
	New MIME constant types have been defined
		- application/openpgp-encrypted
		- application/openpgp-signature
		Quick vote: Do we want these defined? : 4 against : 10+ for
								2xx
abstentions?
	Content transfer encoding restrictions
		- generate strictly, accept liberally
	OpenPGP encrypted data
		Question : MIME or OP encryption first?
		Decision : MIME cannonicalized first, then encrypted
	OpenPGP signed data
		- protocol = application/openpgp-signature
	    		= openpgp-md5
			openpgp-sha1
			openpgp-ripemd160
			openpgp-haval (15 variants)
	Parallel signatures are popular
		RFC1847 based parallel signatures on the same data have been
		defined.
	Distribution of PGP keys
		This text will be moved to PGP certificate document.
	Ned Freed: Ongoing issue with multipart signed messages. The
		issues concern gateways. He encouraged people to read
		and comment on his draft concerning this:
			drafts-freed-gsec-00.txt.

Trust model documents (John Norenberg)
	There are numerous types of trust models.
	It would probably be good to have a document on this. The
		document would cover:
			- What trust models are available.
			- How they work.
			- How they are implemented in the context of PGP.
	Question for group: Do we need this?
	Paul Hoffman: Agrees. Would be good to have a separate
		document on this.
	John Norenberg : Should we vote here or defer this question
		to the list?
	Rodney: Let's take these questions to the list and decide there.

Any other business?
	Blue sheet...all signed? about 40 not yet on list.

John Norenberg summarized what was covered at the meeting. He then closed
the meeting at 3:10 PM (20 minutes ahead of schedule).

john  w noerenberg, ii
[email-masked]
  ------------------------------------------------------------------
  "YOU THINK THEY GIVE YOU THE SHIVERS NOW," Owen said.
 "JUST WAIT UNTIL HE STARTS MAKING DECISIONS!"
  -- John Irving, A Prayer for Owen Meany, 1989
  ------------------------------------------------------------------

From: [email-masked]
DATE: 14 Jan 98 4:15:58 PM
TO: [email-masked]
SUBJECT: CyberNews
Sender: [email-masked]

      LET US DO YOUR BULK MAILINGS!!!

..$350 PER MILLION ADDRESSES SENT
..$250 PER 1/2 MILLION ADDRESSES SENT

THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS!

Our company will do bulk emailing for your product/service.

Addresses are extracted daily by six of our computers,
which run 24 hours a day 7 days a week, scanning the net
for new addresses.  Estimated 60-80,000 addresses extracted 
daily.  They are fresh!  Over 40 million addresses on file.

No more than 2 pages (50 lines), no porn and no foul 
language.  $50 per page/25 lines per page beyond 2 pages.  
We do not do targeted mailings at this price.

Targeted mailings: 
$150 per 50,000 addresses extracted or less.
We can extract by country, occupation, organizations, 
associations, product, etc.  If we can not 
search and extract what you need, then nobody can.

There are no lower prices on the net.  Your mailing 
can be done in a matter of hours.  We have 6 computers 
extracting addresses 24/7.

For the fastest service, cheapest prices and cleanest
mailings call our processing and new accounts office
at 904-282-0945, Monday - Friday 9 - 5 EST.  If the line is
busy, please keep trying, as bulk mailing is growing fast.  
We do want to work with you to advertise your product.

To have your name removed, call our processing office.
Any negative responses will be dealt with accordingly.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 14 Jan 98 13:26:17 -0500
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Lost Messages
Sender: [email-masked]

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

Hi,

In the process of switching to a new sever I have lost several days worth
of mail.

If you have directly messaged me in the past couple of days please resend.

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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: Air conditioned environment - Do not open Windows.

Tag-O-Matic: I'm an OS/2 developer...I don't NEED a life!

Date: Fri, 9 Jan 1998 07:16:35 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Colin Plumb has an amusing quote in the bignum library, where another
algorithm is used that has a failure probability:

"The chances that another Dinosaur Killer asteroid will land today is
about 10^-11 or 2^-36, so it would be better to spend your time worrying
about *that*."

This is assuming that such asteroids hit Earth every billion years or so.
It also assumes that they aren't detectable in advance, which according to
a documentary I saw recently about the late Dr. Gene Shoemaker, is
correct.

Hal

From: Andrew Bromage <[email-masked]>
Subject: Re: Speculative Mode for KeyIDs of all zeroes
To: [email-masked] (Bill Stewart)
Date: Fri, 9 Jan 1998 20:34:26 +1100 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

G'day all.

Bill Stewart wrote:

> The probability of a generating a key with KeyID of 0 is 2**-64.
> It could happen by accident, though it probably won't, and worst case is
> the lucky user of such a key will just have to check all messages 
> sent to him that have KeyID 0 against all his keys.
> Annoying, but no loss of functionality.

Is it so hard for a key generator to guarantee that it never produces
a 64 bit key of ID 0?  Generate another, or massage the original key in
a random way.

If you amortise the cost over all decryptions to be performed with that
key, it probably turns out to be cheaper.

Cheers,
Andrew Bromage

To: David Sternlight <[email-masked]>
CC: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: The web of trust has no clothes.
Date: Sat, 20 Dec 1997 10:32:58 +0100 (MET)
Lines: 25
Sender: [email-masked]

On Mon, 24 Nov 1997, David Sternlight wrote:

-> not only does everyone with an old RSA key have to generate a new key
-> but also a complete new set of signatures and web of trust must be built
-> if they wish to use the "better" algorithms. And the new keys must be

 That's easy:

 - Generate your new key.
 - Sign it with your old key, possibly send it clear-signed or whatever.
 - Send it to the persons who signed your old key. They can verify your
   signature on the new key and since they checked you're the one with
   the old key, they can validly assume you signed the new one allright.
 - After this verification, they can sign the new key and send it back.

 - In the unlikely event that someone got hold of your secret key, they
   can simply revoke their sgnatures. It's really unlikely, however.

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
  # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
    "Das kann doch nicht so schwer sein, so ein paar Header zu erzeugen!"
                                             (Eike Rathke auf der Gatebau'97)

Date: Thu, 8 Jan 1998 00:22:15 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: message integrity checksum?
Sender: [email-masked]

David Formosa <[email-masked]> writes:
> On Tue, 6 Jan 1998, Adam Back wrote:
> 
> > Gary Howland discussed PGP vulnerabilities at HIP97 I think.  One of
> > the vulnerabilities was that encrypted (but not signed) messages could
> > be altered undetectably.
> 
> This vulnerability is commen to any system that is encrypted but not
> signed.

Not necessarily, it just depends if this property has been designed
into the protocol design.  For example SSLv3 has cipher suite
ADH-DES-CBC3-SHA -- this cipher suite is not signed -- it is
symmetrically encrypted with 3DES, but it also has an HMAC based
authentication code with keying material derived from session data.

It is vulnerable to MITM, however because there is no authentication
at all.

Many systems are based on symmetric key technology only, where
shared-key authentication mechanisms are used.

This is why I asked "is this considered a problem?"

It could be a problem if people assume this property.  I think it
would be a useful property to add.  Either add, or note lack of this
property as a security warning.

I have some vague recollection that PGP said shortly after Gary gave
his talk that they had addressed the security problem(s) that Gary
raised.  It would appear that the modifiable unsigned bulk encrypted
data has not been fixed unless I missed this in the currrent draft.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Tue, 06 Jan 1998 22:08:27 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: OpenPGP IETF meeting -- what happened? (Re: section 4.3)
Cc: [email-masked]
Sender: [email-masked]

At 10:40 PM 12/31/1997 GMT, Adam Back wrote:
>> This is a good explanation.  Thanks for providing it.  There has been so
>> much attention paid to the additional recipient feature that few people have
>> had the energy to look at the other new features.
>
>What happened to the ARR anyway?  Is it still there?  What happened at
>IETF?

I don't know about the IETF meeting discussion of it, but the ARR (etc.)
is Yet Another Subpacket Type, and therefore has a known size and 
can be skipped over if it's not implemented.  So if we don't document it
and don't talk about it, everything works, or if we document the
subpacket type number as "Reserved For Evil Eavesdroppers",
everything still works.

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

Date: Wed, 7 Jan 1998 10:20:18 +1100 (EST)
From: ? the Platypus {aka David Formosa} <[email-masked]>
Reply-To: [email-masked]
To: Adam Back <[email-masked]>
cc: [email-masked]
Subject: Re: message integrity checksum?
Sender: [email-masked]

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

On Tue, 6 Jan 1998, Adam Back wrote:

> Gary Howland discussed PGP vulnerabilities at HIP97 I think.  One of
> the vulnerabilities was that encrypted (but not signed) messages could
> be altered undetectably.

This vulnerability is commen to any system that is encrypted but not
signed.  It is not a perculartity of PGP.  

> Clearly one way to fix it is to use signatures.

Of cause.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my
header. Never trust a country with more peaple then sheep.  ex-net.scum
and proud You Say To People "Throw Off Your Chains" And They Make New
Chains For Themselves? --Terry Pratchett. 

Date: Tue, 6 Jan 1998 22:38:07 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: message integrity checksum?
Sender: [email-masked]

Gary Howland <[email-masked]> writes:
> Adam Back <[email-masked]> wrote:
> > [lack of integrity check in PGP bulk symmetric encryption]
> > 
> > I think the example given is that someone might use this (symmetric
> > encryption) to send commands to a remote command executer which would
> > be trusted because it was encrypted with a shared passphrase.  This
> > shows that the last command say could be garbled, resulting in a null
> > operation and potential security problem.
> 
> With known plaintext, the last 8 bytes can be set to anything the attacker 
> desires - so it's not just a case of removing or randomly corrupting data.

Indeed.  Worse than that even -- you can modify arbitrary blocks, and
because of the way ciphertext error propagation works in 64 bit (ie in
cipher block size feedback) CFB mode only the following block will be
garbled, further blocks will recover.

The last block can be altered without any garbling at all because
there is no following block.

> You can find the paper for the talk at:
> 
> 	http://www.hotlava.com/doc/index.html

Perhaps you covered the above, as I hadn't read your paper; will read.

Of course the attack is harder if one must cope with compression --
when we discussed this before you considered it possible to do even
with compression -- I tend to agree, though it will limit your
flexibility in that you will likely have to limit yourself to last
block attacks otherwise the following garbled block will likely
corrupt the compression, plus you will be limited to matching the
compression message bit length which is stored inside the encryption
envelope.  (I am presuming compression is not necessarily a mulitple
of 8 bits long -- this assumption could be wrong, as I am not familiar
with ZIP algorithm, this assumption is based on huffman encoding).

Ciphertext error recovery properties have interesting implications for
protocol modifications to add message integrity protection -- for
instance appending a MD5 digest of the message to the plaintext prior
to encryption would not solve the problem.

I think a keyed MAC such as HMAC would do the trick with the MAC key
and the MAC output both being inside the encryption envelope.  

You would want to check that MAC key and ouput position alignment and
padding in the modified protocol do not weaken the brute force
resistance to modification provided by the MAC key size.

Adam

To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: message integrity checksum? 
Date: Tue, 06 Jan 1998 22:38:01 +0100
From: Gary Howland <[email-masked]>
Sender: [email-masked]

> 
> Gary Howland discussed PGP vulnerabilities at HIP97 I think.  One of
> the vulnerabilities was that encrypted (but not signed) messages could
> be altered undetectably.
> 
> This can be demonstrated (with pgp2.6 command line):
> 
> % echo hello world > junk
> % pgp -c +compress=off -zfred junk
> % sed 's/....$/adam/' < junk.pgp > junk2.pgp
> % pgp -zfred junk2.pgp
> % cat junk2
> hello wo<F8>P?t
> 
> (pgp doesn't complain or even notice the above ... there is no
> checksum and so you can just garble the file, if you so wish, and pgp
> won't complain).
> 
> Was this viewed as a problem?
> 
> I think the example given is that someone might use this (symmetric
> encryption) to send commands to a remote command executer which would
> be trusted because it was encrypted with a shared passphrase.  This
> shows that the last command say could be garbled, resulting in a null
> operation and potential security problem.

With known plaintext, the last 8 bytes can be set to anything the attacker 
desires - so it's not just a case of removing or randomly corrupting data.

You can find the paper for the talk at:

	http://www.hotlava.com/doc/index.html

Gary

Date: Tue, 6 Jan 1998 18:31:21 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: message integrity checksum?
Sender: [email-masked]

Gary Howland discussed PGP vulnerabilities at HIP97 I think.  One of
the vulnerabilities was that encrypted (but not signed) messages could
be altered undetectably.

This can be demonstrated (with pgp2.6 command line):

% echo hello world > junk
% pgp -c +compress=off -zfred junk
% sed 's/....$/adam/' < junk.pgp > junk2.pgp
% pgp -zfred junk2.pgp
% cat junk2
hello wo<F8>P?t

(pgp doesn't complain or even notice the above ... there is no
checksum and so you can just garble the file, if you so wish, and pgp
won't complain).

Was this viewed as a problem?

I think the example given is that someone might use this (symmetric
encryption) to send commands to a remote command executer which would
be trusted because it was encrypted with a shared passphrase.  This
shows that the last command say could be garbled, resulting in a null
operation and potential security problem.

The same problem applies to RSA (or Elgamal), encrypted messages, as
the bulk of the data is encrypted with a block cipher essentially the
same as the symmetric cipher only.

Clearly one way to fix it is to use signatures.

Was there any thought given to using a MAC, checksum, or message
digest added to the message to prevent modification without knowing
the key?

Adam

From: Curtis Yarvin <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
To: [email-masked] (A. Padgett Peterson P.E. Information Security)
Date: Fri, 2 Jan 1998 10:50:06 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

> For that matter PGP plugs in directly to EXCHANGE and EUDORA. To me
> this just shows the impossibility of such a reg. unless plugins can
> be owtlawed completely (of course that has never bothered any court 
> since King Canute).

A slur!  I must defend the name of good King Canute.

Canute (Knut), a Danish king of England around 900 AD, was a
fine ruler.  In his reign, peace and high culture were
restored; banditry was suppressed.  He united Anglo-Saxon,
British, and Danish peoples of England in a single
prosperous kingdom.

Canute (at least, according to the story) did have his
throne carried down to the beach, did command the tide not
to come in, and did sit there until it washed over his feet.
However, his point was not to demonstrate his omnipotence,
but his lack of such, to quit the flattery of his courtiers.

Thus, Canute should not be remembered for arrogance and
pomposity, but for wisdom, discretion, a good sense of
humor, and strong managerial skills.  Of course, the art
of government has come a long way since the Dark Ages:
it's unfair to compare him to any of our modern rulers.

Curtis

Date: Fri, 02 Jan 1998 12:01:38 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>Incidentally, I think this is probably a dangerous course of
>action. The EAR <http://www.bxa.doc.gov/supp6.htm> 7 day review
>criteria explicitly state:

>   (iv) The software must not allow the alteration of the data 
>encryption mechanism and its associated key spaces by the user or 
>any other program

For that matter PGP plugs in directly to EXCHANGE and EUDORA. To me
this just shows the impossibility of such a reg. unless plugins can
be owtlawed completely (of course that has never bothered any court 
since King Canute).

Unless, of course, a good Kentuck lawyer could argue that "your honour,
our program has not altered the data encryption mechanism or its associated 
key spaces, they are completely intact (just bypassed)." (and the MIB would 
come around with their little flasher thingie...).

					Warmly,
						Padgett

Date: Thu, 1 Jan 1998 21:02:16 -0800
To: EKR <[email-masked]>
From: Steve Schear <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 7:34 PM -0800 1/1/98, EKR wrote:
>You write:
>> >Incidentally, I think this is probably a dangerous course of
>> >action. The EAR <http://www.bxa.doc.gov/supp6.htm> 7 day review
>> >criteria explicitly state:
>> >
>> >   (iv) The software must not allow the alteration of the data=20
>> >encryption mechanism and its associated key spaces by the user or=20
>> >any other program
>> >
>> >It seem that Fortify is a constructive proof that the program
>> >in question violates this criterion. That doesn't mean it's
>> >ineligible for CJ completely but I wouldn't want to try to get
>> >approval for it either.
>>=20
>> I'm sure the EAR enforcement folks are well aware of how well or poorly=
 various software they approve for export adhere to regulation.  I'll leave=
 it to the individual corporations and EAR to soft this out.
>>=20
>> The point I was trying to make is that from a practical standpoint
>> companies like Netscape need change nothing.  Just keep their code
>> structured the same way and let unrelated 3rd parties "do the dirty
>> work."=20
>I think we're in violent agreement here, then.

Some companies have a strong idiological calling and need to follow that=
 star (i.e., PGP).  Others are spineless jellyfish who go along to get=
 along, hoping that this path will keep them in the good graces of the Dept.=
 of Commerce.  Many fall somewhere in between. =20

I don't see Netscape playing the martyr or using PGP/C2's legal guerilla=
 tactics to enbable strong crypto systems and applications, it's just not=
 their style.  They do seem to be, however, keenly aware of the PR=
 associated with championing reliable transaction privacy and the adverse PR=
 from being hacked (especially from weak crypto).  Keeping their products=
 hackable, perhaps even anonymously supporting those doing the hacking,=
 while staying within the letter of the law and publicly and privately=
 pressuring for true crypto reform might be their best course.

=46or many, including myself, guerilla tactics are more attractive due to=
 economic factors.  Also, I have less to lose.

--Steve

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
---------------------------------------------------------------------
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]
---------------------------------------------------------------------

	I know not what course others may take; but as for me,=20
	give me ECache or give me debt!

	"It's your Cache=81"

To: Steve Schear <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP 
Date: Thu, 01 Jan 1998 19:34:59 -0800
From: EKR <[email-masked]>
Sender: [email-masked]

You write:
> >Incidentally, I think this is probably a dangerous course of
> >action. The EAR <http://www.bxa.doc.gov/supp6.htm> 7 day review
> >criteria explicitly state:
> >
> >   (iv) The software must not allow the alteration of the data 
> >encryption mechanism and its associated key spaces by the user or 
> >any other program
> >
> >It seem that Fortify is a constructive proof that the program
> >in question violates this criterion. That doesn't mean it's
> >ineligible for CJ completely but I wouldn't want to try to get
> >approval for it either.
> 
> I'm sure the EAR enforcement folks are well aware of how well or poorly various software they approve for export adhere to regulation.  I'll leave it to the individual corporations and EAR to soft this out.
> 
> The point I was trying to make is that from a practical standpoint
> companies like Netscape need change nothing.  Just keep their code
> structured the same way and let unrelated 3rd parties "do the dirty
> work." 
I think we're in violent agreement here, then.

-Ekr

[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Thu, 1 Jan 1998 17:40:52 -0800
To: EKR <[email-masked]>
From: Steve Schear <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>> At 7:00 PM -0800 12/31/97, EKR wrote:
>Sorry I wasn't clear. The point I was trying to make was
>that Netscape would still have to ship their export products, no?
>Otherwise Fortify doesn't work, right? That said, there will be
>a lot of people who don't bother to upgrade (just like there
>are a lot of Americans who don't bother to get the domestic
>Netscape.) Consequently, we've still got a lot of export
>SSL implementations floating around. Does that seem like a=20
>reasonable assessment of the situation to you?

Like markets, in which there will always be some who pay more or less for=
 the same item/service due primarily to their knowledge, there will be those=
 who's communications will be more easily compromised and other's who will=
 not. This is a job for the media and informed Netizens: to educate their=
 brethern about how secure the software they use is against various=
 individuals or organizations which would seek to read their email, and what=
 they can do about it.=20

>
>Incidentally, I think this is probably a dangerous course of
>action. The EAR <http://www.bxa.doc.gov/supp6.htm> 7 day review
>criteria explicitly state:
>
>   (iv) The software must not allow the alteration of the data=20
>encryption mechanism and its associated key spaces by the user or=20
>any other program
>
>It seem that Fortify is a constructive proof that the program
>in question violates this criterion. That doesn't mean it's
>ineligible for CJ completely but I wouldn't want to try to get
>approval for it either.

I'm sure the EAR enforcement folks are well aware of how well or poorly=
 various software they approve for export adhere to regulation.  I'll leave=
 it to the individual corporations and EAR to soft this out.

The point I was trying to make is that from a practical standpoint companies=
 like Netscape need change nothing.  Just keep their code structured the=
 same way and let unrelated 3rd parties "do the dirty work."

--Steve

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jan 98 15:36:23 -0600
To: EKR <[email-masked]>
Cc: Steve Schear <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

In <[email-masked]>, on 01/01/98 
   at 03:29 PM, EKR <[email-masked]> said:

>It seem that Fortify is a constructive proof that the program in question
>violates this criterion. That doesn't mean it's
>ineligible for CJ completely but I wouldn't want to try to get approval
>for it either.

Personaly I think it would be a far better thing to allow *no* crypto
products be exported rather than the current government mandated
snake-oil.

FWIW: Most people I talk to that need the strong crypto version overseas
get it from replay.com :)

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jan 98 15:02:32 -0600
To: Hal Finney <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Key Extraction odd behavior ???
Sender: [email-masked]

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

In <[email-masked]>, on 01/01/98 
   at 11:39 AM, Hal Finney <[email-masked]> said:

>What is packet type 14?  You seem hung up on the idea that it is a
>signature packet.  It's not!  Look at section 4.3:

Yes, after a good nights sleep and some help from Patrick I was able to
figure it out.

Part of my mental block was I *knew* that there should have been a sig
packet following the userID packet.

As far as the striping of the signatures:

I did a pgpk -x [keyID] -o [outfile]

The signature packets should have been retained in the extracted key in
the outfile but for some reason they were striped.

I have not been able to isolate the exact triger for this happening as I
have latter done the same operation and had the sig packets retained.

IMHO I can not see any reason for a sig packet to be removed from a key
unless they are flaged as non-exportable or the user explicitly removes
them.

This seems to be some type of bug in the 5.0i code as I have had other
problems with the pgpk code from this build (b8a).

BTW any ideal what setting a key as "axiomatic" does??

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jan 98 14:52:36 -0600
To: Steve Schear <[email-masked]>
Cc: EKR <[email-masked]>, EKR <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

In <v0310280ab0d195b3e11b@[208.129.55.202]>, on 01/01/98 
   at 10:58 AM, Steve Schear <[email-masked]> said:

>Sure it does. (Hello, are you listening?) Fortify modifies the currently
>shipping, currently export approved Navigator/Communicator, allowing
>users anywhere to use its 128-bit SSL whenever they connect with a
>128-bit capable SSL server (say a cypherpunk server at XS4all in the
>Netherlands).  Normally, 128-bit SSL is only enabled when these browsers
>connect with an SSL server which has a "supercert" issued with U.S. gov't
>approval (mostly to U.S. banks).

>So strong crypto is now available, via an easily applied patch, to the
>most widely used export approved product.

Another approach that I have been playing with is the use of local crypto
proxies.

One would have a HTTP/SSL proxie that uses strong crypto and comes with
source code. One mearly connects their web borwser to their proxie and the
proxie handles all the crypto. For non crypto sites it would just pass the
pages and requests through unmolested.

I have also looked into adding SSH capabilities to this so even non-SSL
sites one can still tunnel via SSH for an encrypted link.

A similar approach can be used for addressing the weak S/MIME crypto
produced by NS, MS, et al.

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

To: Steve Schear <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP 
Date: Thu, 01 Jan 1998 12:29:57 -0800
From: EKR <[email-masked]>
Sender: [email-masked]

> At 7:00 PM -0800 12/31/97, EKR wrote:
> >In message <v03102805b0d08d63c7cc@[208.129.55.202]>, Steve Schear writes:
> >>How about funding programs such as Fortify, which patch browsers to enable 128
> >>-bit SSL with all willing servers (whether or not they have supercerts)?
> >That seems like a fine plan, but it doesn't really speak to what
> >Netscape ships as a Netscape product, does it?
> >
> >-Ekr
>  Sure it does. (Hello, are you listening?) Fortify modifies the
> currently shipping, currently export approved
> Navigator/Communicator, allowing users anywhere to use its 128-bit
> SSL whenever they connect with a 128-bit capable SSL server (say a
> cypherpunk server at XS4all in the Netherlands).  Normally, 128-bit
> SSL is only enabled when these browsers connect with an SSL server
> which has a "supercert" issued with U.S. gov't approval (mostly to
> U.S. banks).
>  So strong crypto is now available, via an easily applied patch, to
> the most widely used export approved product.
Sorry I wasn't clear. The point I was trying to make was
that Netscape would still have to ship their export products, no?
Otherwise Fortify doesn't work, right? That said, there will be
a lot of people who don't bother to upgrade (just like there
are a lot of Americans who don't bother to get the domestic
Netscape.) Consequently, we've still got a lot of export
SSL implementations floating around. Does that seem like a 
reasonable assessment of the situation to you?

Incidentally, I think this is probably a dangerous course of
action. The EAR <http://www.bxa.doc.gov/supp6.htm> 7 day review
criteria explicitly state:

   (iv) The software must not allow the alteration of the data 
encryption mechanism and its associated key spaces by the user or 
any other program

It seem that Fortify is a constructive proof that the program
in question violates this criterion. That doesn't mean it's
ineligible for CJ completely but I wouldn't want to try to get
approval for it either.

-Ekr
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Thu, 1 Jan 1998 11:39:01 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Key Extraction odd behavior ???
Sender: [email-masked]

William, simply decode the packets as specified by the draft:

0xb9 = 10111001 =  10 1110 01, packet type 14.

What is packet type 14?  You seem hung up on the idea that it is a
signature packet.  It's not!  Look at section 4.3:

: 0        -- Reserved. A packet must not have a tag with this value.
: 1        -- Encrypted Session Key Packet
: 2        -- Signature Packet
: 3        -- Conventionally Encrypted Session Key Packet
: 4        -- One-Pass Signature Packet
: 5        -- Secret Key Packet
: 6        -- Public Key Packet
: 7        -- Secret Subkey Packet
: 8        -- Compressed Data Packet
: 9        -- Symmetrically Encrypted Data Packet
: 10       -- Marker Packet
: 11       -- Literal Data Packet
: 12       -- Trust Packet
: 13       -- Name Packet
: 14       -- Subkey Packet
: 15       -- Reserved
: 16       -- Comment Packet

Packet type 14 is a subkey packet.  It's not a signature packet.  You are
completely mistaken in trying to interpret it as one.

The format of packet type 14 is in section 5.5.1.2 of the draft, where
it is explained that the same format is used as for a public key packet.
These are defined in 5.5.2.  There you will see:

: A version 4 packet contains:
:     - A one-octet version number (4).
:     - A four-octet number denoting the time that the key was created.
:     - A one-octet number denoting the public key algorithm of this key
:     - A series of multi-precision integers comprising the key      
:       material.  This algorithm-specific portion is:
: 
:     Algorithm Specific Fields for RSA public keys:
:     - multiprecision integer (MPI) of RSA public modulus n;
:     - MPI of RSA public encryption exponent e.
: 
:     Algorithm Specific Fields for DSA public keys:
:     - MPI of DSA prime p;
:     - MPI of DSA group order q (q is a prime divisor of p-1);
:     - MPI of DSA group generator g;
:     - MPI of DSA public key value y (= g**x where x is secret).
: 
:     Algorithm Specific Fields for Elgamal public keys:
:     - MPI of Elgamal prime p;
:     - MPI of Elgamal group generator g;
:     - MPI of Elgamal public key value y (= g**x where x 
:       is secret).

This will explain the format of your packet.

As to your problem with the signatures sometimes being exported and
sometimes not: this usually means you are changing to a different public
keyring without also changing your secret keyring.  Signature packets
are stored on the public keyring only, in 5.0 and earlier versions.
Key and userid packets are stored on both public and private keyrings.

If you change to a different public keyring file, you'll still see
your old key and userid, because they are stored on the secret keyring,
which you didn't change.  But if you look for signatures, you will see
that they are now absent.  That is because they were only stored in
the original public keyring file.  If you export now you will get a key
without signatures.

This behavior goes back to PGP 2.X, and is due to the desire to segregate
the sensitive key material from the public material.  However there is
some worry that it causes confusion like it has for you, and therefore
we might want to consider abandoning the dual-key-ring model and go to
a single file to store all the key/certificate information.

Hal Finney
PGP, Inc.

Date: Thu, 01 Jan 1998 14:11:25 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

DRAT. I remember seeing somewhere that changing the crypto in
either EXCHANGE or NETSCAPE (might be both) was a matter of 
exchanging a .DLL but cannot recall the citation - anyone
here know ?
				Hippo Neuw Jahr,
						Padgett

Date: Thu, 1 Jan 1998 10:58:03 -0800
To: EKR <[email-masked]>
From: Steve Schear <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: EKR <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 7:00 PM -0800 12/31/97, EKR wrote:
>In message <v03102805b0d08d63c7cc@[208.129.55.202]>, Steve Schear writes:
>>At 2:25 PM -0800 12/31/97, EKR wrote:
>>>Will Price <[email-masked]> writes:
>>>> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:
>>
>>[big snip]
>>>Try to solve the following two examples:
>>>Netscape and Microsoft. Netscape has downloads off their web site.
>>>They want them to be easy. That means that the user can just
>>>point and click. That means the crypto must be exportable or none
>>>at all. Which do you suggest?
>>>Next consider Microsoft. They embed their browser in the OS (at
>>>least for now.). They want to ship that to foreigners. Again,
>>>the crypto has to be exportable or nonexistent. Which do you
>>>suggest?
>>>
>>>So, what do you suggest these companies do?
>>
>>How about funding programs such as Fortify, which patch browsers to enable=
 128
>>-bit SSL with all willing servers (whether or not they have supercerts)?
>That seems like a fine plan, but it doesn't really speak to what
>Netscape ships as a Netscape product, does it?
>
>-Ekr

Sure it does. (Hello, are you listening?) Fortify modifies the currently=
 shipping, currently export approved Navigator/Communicator, allowing users=
 anywhere to use its 128-bit SSL whenever they connect with a 128-bit=
 capable SSL server (say a cypherpunk server at XS4all in the Netherlands). =
 Normally, 128-bit SSL is only enabled when these browsers connect with an=
 SSL server which has a "supercert" issued with U.S. gov't approval (mostly=
 to U.S. banks).

So strong crypto is now available, via an easily applied patch, to the most=
 widely used export approved product.

--Steve

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jan 98 12:56:05 -0600
To: Patrick Feisthammel <[email-masked]>
Cc: IETF OpenPGP Mailinglist <[email-masked]>, [email-masked]
Subject: Re: Key Extraction odd behavior ??? [Solved]
Sender: [email-masked]

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

In <[email-masked]>, on 01/01/98 
   at 07:40 PM, Patrick Feisthammel <[email-masked]> said:

>"A Public Subkey packet (tag 14) has exactly the same format as a Public
>Key packet, but denotes a subkey"

Sorry People, I guess I shouldn't read rfc's at 2am. :)

I was mistaking the "Public Subkey Packet" for a Signature SubPacket.

Forget all my previous ranting.

Still don't know why PGP 5.0 striped off the sigs when exporting the key
but that is not an issue for OpenPGP.

Thanks Patrick for putting up with my ranting. :)

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Thu, 1 Jan 1998 19:40:54 +0100 (CET)
From: Patrick Feisthammel <[email-masked]>
Reply-To: Patrick Feisthammel <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: IETF OpenPGP Mailinglist <[email-masked]>, [email-masked]
Subject: Re: Key Extraction odd behavior ???
Sender: [email-masked]

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

Hi!

> Version Number is defined for Signature Packets (Type 2) and not for
> Signatuer Subpacket (Type 14).

It is not a signature packet (typ 2). In teh OpenPGP draft you find:
5.5.1.2 Public Subkey Packte (Tag 14):

"A Public Subkey packet (tag 14) has exactly the same format as a Public
Key packet, but denotes a subkey"

The Public Key Packet (Tag 6): "starts a series of packets that forms an
OP key".

(I think in the specs in chapter 5.5.1.1 should be a forward reference to
the chapter 5.5.2)

Some lines later in 5.5.2 "Public Key Packet Formats":
"There are two versions of key-material packets. Version 3..."

> The next octet is 0x34 what is that?? It doesn't match as a signature type
> nor does it match for a signatuer subpacket type.

The version 4 packet contains: 
" - A one-octed version number (4).
  - A four-octet number denoting the time that the key was created.
  ...
"

>>[B9] [04 0D] 04 34 A3 DF 8E ...

so 34 A3 DF 8E 
is the time the key was created. (I think late in 1997, not exactly
calculated)

> Also in the spec it does not define exactly which bits from a subpacket
> type octet are to be used for determining the value? Bit 7 is defined as a
> critical flag so do we use the remaining 6-0 bits or a subset of that?

I could not find an exact definition. The last 5 Bits (Bits 4-0) must be
for the type, Bit 7 is the critical Bit. So there are still Bit 5 and 6
left.  Maybe they will become some special meaning in the future, maybe
they are just used for furthter packages... 

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)

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jan 98 10:08:53 -0600
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Key Extraction odd behavior ???
Sender: [email-masked]

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

In <[email-masked]>, on 01/01/98 
   at 10:05 AM, Patrick Feisthammel <[email-masked]> said:

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

>Hi!

>> If [B9] is the packet type and [04 0D] the packet length what is the next
>> [04]?

>B9= 1011 1001
>10= old packet type
>1110= packet typ 14 (decimal) 
>01-> 2 octed length 

>I think it is a packet 14 (subkey packet), 040d is the length. the next
>04 is the version number (version 4 packet)
>as given in the OpenPGP draft in Chapter 5.5.2. Public Key Packet
>Formats.

Hi Patric,

Unfortunatly this doen not seem to work.

Version Number is defined for Signature Packets (Type 2) and not for
Signatuer Subpacket (Type 14).

The next octet is 0x34 what is that?? It doesn't match as a signature type
nor does it match for a signatuer subpacket type.

Also in the spec it does not define exactly which bits from a subpacket
type octet are to be used for determining the value? Bit 7 is defined as a
critical flag so do we use the remaining 6-0 bits or a subset of that?

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Thu, 1 Jan 1998 16:05:46 +0100 (CET)
From: Patrick Feisthammel <[email-masked]>
Reply-To: [email-masked]
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Key Extraction odd behavior ???
Sender: [email-masked]

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

Hi!

> If [B9] is the packet type and [04 0D] the packet length what is the next
> [04]?

B9= 1011 1001
10= old packet type
1110= packet typ 14 (decimal) 
01-> 2 octed length 

I think it is a packet 14 (subkey packet), 040d is the length.
the next 04 is the version number (version 4 packet)
as given in the OpenPGP draft in Chapter 5.5.2. Public Key Packet Formats.

Hope it helps :-)

Cheers, Patrick

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 01 Jan 98 02:47:06 -0600
To: [email-masked], [email-masked]
Subject: Re: Key Extraction odd behavior ???
Sender: [email-masked]

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

In <[email-masked]>, on 01/01/98 
   at 01:10 AM, "William H. Geiger III" <[email-masked]> said:

>Hi,

>Well somthing screwy is going on.

>I have now after doing several extracts of the same key from pubring.pkr
>have two different keys?!?

>I have the one of filesize 1504 that was attached to the previous message
>and one of 1800 that seems to have the sig block properly
>formatted.

Ok I figured out *what* it is doning but not why.

The original key had 2 sigs on it; one a self-sig and the other a RSA sig
from my RSA key.

The key contained packets:

Public Key Packet
UserID Packet
Signature Packet (self-sig)
Signature SubPacket
Signatuer Packet (RSA sig)

For some reason in the extracted key in the first message both signature
packets had been striped from the key when extracted while in the
extracted key in the second message they were retained. I still do not
know what triggered this behavior.

Well with that figured out I am back to my original problem of decyphering
the Signature Subpacket.

What I need to know is the following:

[B9] [04 0D] 04 34 A3 DF 8E ...

If [B9] is the packet type and [04 0D] the packet length what is the next
[04]?

If [04] is a subpacket length then what is the [34]?

0x34 = 00110100 = 52 which is an undefined subpacket type

If [04] is a subpacket type (exportable) where is the corresponding octet
flag?

I have been up all night reading through the draft on this and still have
not made any headway. :((

- -- 
- ---------------------------------------------------------------
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 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------