Subject: PGP/MIME interop testing: Very first steps towards a test suite.

From: Thomas Roessler <[email-masked]>
Date: Wed, 29 Mar 2000 19:29:05 +0200

I've started work on a suite of test messages which are
intended to help verify the correctness of the receiving
end of a PGP/MIME implementation.  Currently, I'm using
PGP 2.6.3in and RSA/MD5 for the underlying encryption and
signature creation, however, this can easily be changed to
a more modern version of PGP or GnuPG - the messages are
generated by a shell script, which does all the MIME stuff
"by hand", so no actual MUA is involved with the creation
of these messages.

The set of messages I have so far is quite simple.
Generally, I try to poke a bit at the interaction between
the MIME and PGP layers, and at crucial features which
should better be present on the PGP layer if PGP/MIME
should work.

- Problems I encountered in the past with the interaction
  of MIME and PGP/MIME engines - this includes things like
  quotes around boundary parameters where they aren't
  needed and positions of parameters (I've chosen a
  hopefully sufficiently strange order to expose eventual
  bugs here; we may wish to check all permutations in the
  future).

- Binary and text-mode signatures.  The PGP/MIME text
  doesn't specify what to send, and actually both types
  are valid and should work neatly.  However, this should
  be verified.

- Trailing whitespace.  I've seen this break some
  back-ends.

- Unterminated last lines.  It seems that there has been
  some confusion about how this should be handled in the
  past.

Those who are interested in trying this, please have a
look at:

ftp://riemann.iam.uni-bonn.de/pub/users/roessler/pgpmime-interop/

This directory contains 5 files:

- forms.txt is a first take at a report form.

- interop.maildir.tar is a tar archive which contains a
  maildir folder with the 36 test messages.  Essentially,
  this is a directory structure where every message is
  stored in a file of it's own.

- interop.mbox is an mbox folder which contains the 36
  test messages.

- interop.pgp.tar contains the pubring.pgp and secring.pgp
  files with the key I use for testing.  The pass phrase
  is "none".

- interop.src.tar contains the shell script and a small C
  helper program I use to create the messages.

Comments are highly welcome.  Also, please notify me
immediately if my script is generating illegal messages
(although I hope not to do this).

-- 
http://www.guug.de/~roessler/

---

From: Ian Bell <[email-masked]>
Date: Thu, 30 Mar 2000 11:09:56 +0100

>  are valid and should work neatly.  However, this should

 From RFC2015:

2.  PGP data formats

    PGP can generate either ASCII armor (described in [3]) or 8-bit
    binary output when encrypting data, generating a digital signature,
    or extracting public key data.  The ASCII armor output is the
    REQUIRED method for data transfer.

So binary-mode signatures are forbidden, and remain so in the new draft.

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

---

From: Thomas Roessler <[email-masked]>
Date: Thu, 30 Mar 2000 12:36:06 +0200

On 2000-03-30 11:09:56 +0100, Ian Bell wrote:

>     PGP can generate either ASCII armor (described in
>     [3]) or 8-bit binary output when encrypting data,
>     generating a digital signature, or extracting
>     public key data.  The ASCII armor output is the

> So binary-mode signatures are forbidden, and remain so

We are talking about different things here.  

What you are quoting concerns PGP's _output_ format.

The test is about signature types 0 (binary document) and
1 (canonical text document), see section 5.2.1 of RFC
2440.  The point here is that, with type 0 signatures, any
PGP/MIME implemenation must make sure that the proper line
endings are passed to the PGP back-end, while, with type 1
signatures in mind, one may be tempted to short-cut this
requirement from the PGP/MIME document and leave line-end
con versions to the back-end.

(Note that this should actually work nicely when
_generating_ signatures.  Actually, I don't even know
whether any existing implementation really generates type
0 signatures with PGP/MIME.)

---

From: Jon Callas <[email-masked]>
Date: Thu, 30 Mar 2000 17:27:42 -0800

>So binary-mode signatures are forbidden, and remain so in the new draft.

I don't think so.

There are two issues here -- the "mode" of the signature and the format of
the output.

The mode of the signature takes into account whitespace and line-end issues.

The format of the output is whether the OpenPGP packets are put in raw
binary, or are ASCII armored.

What this is saying is that you have to use ASCII armor in OpenPGP/MIME.
It's not saying that you can't have a binary mode signature. If you are
using OpenPGP/MIME to sign a zip file (for example), you do it in binary
mode, but you armor the output.

Clear as mud?

	Jon

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 31 Mar 2000 11:33:36 +0200

On 2000-03-30 17:27:42 -0800, Jon Callas wrote:

> What this is saying is that you have to use ASCII armor
> in OpenPGP/MIME. It's not saying that you can't have a
> binary mode signature. If you are using OpenPGP/MIME to
> sign a zip file (for example), you do it in binary

Not necessarily.  Since the zip file will be MIME-encoded
before signing, you can also use a text-mode signature for
this. ;-)

---

From: Ian Bell <[email-masked]>
Date: Fri, 31 Mar 2000 11:51:00 +0100

>There are two issues here -- the "mode" of the signature and the format of

I realize that now from Thomas' reply!

>If you are

It is a requirement that in PGP/MIME messages the signature is
calculated over the canonicalized and encoded data. By the time you
calculate the signature, the zip file data is base64 with CRLF line
endings. So:

* Is it still possible to use a binary mode signature (I think the
  answer is "yes")?

If so,

* Is there any point in using a binary-mode signature over data which by
  this point is CRLF-terminated lines of us-ascii characters?

* Can this (unnecessary) use of binary-mode lead to
  backwards-compatibility problems?

* If there are compatibility problems, shouldn't there be a "SHOULD NOT
  use binary mode signatures" in the openPGP/MIME draft?

Turnpike is not an openPGP client (we use the PGP sdk itself for our
cryptographic operations) - hence there may be more things here that I
have overlooked. My interest in openPGP primarily concerns
interoperability and new extensions (like the multiple signature draft).

---

From: Jon Callas <[email-masked]>
Date: Fri, 31 Mar 2000 15:47:56 -0800

>* Is it still possible to use a binary mode signature (I think the

I would think yes. Thomas's comment notwithstanding, if you encrypt and
sign a binary file, you want to use binary mode. If you can't encrypt and
sign a binary file, then PGP/MIME is mostly worthless.

>  this point is CRLF-terminated lines of us-ascii characters?

Maybe. It depends on the semantic comment of the file.

>  use binary mode signatures" in the openPGP/MIME draft?

Consider this to be pretty much the same as text mode VS binary mode in FTP.

If you send a binary file in text mode, you can end up with problems,
depending on what the sender and receiver think constitutes a line end.
This ends up essentially being data corruption and an interoperability
problem. For example, if you send a binary file in text mode from a unix
system to an NT system, then the NT system will replace all 0x10
(pseudo-LFs) with 0x1310 (pseudo-CRLF). If you then pull it back to a unix
system in text mode, this will be undone. But if you transfer it in binary
mode, you have garbage added bytes. If you were really unlucky and you then
got the file in text mode on a Mac, then the 0x1310s will all become 0x13s.

If you send a text file in binary mode, then it might end up on another
system with the wrong flavor of line ends.

Needless to say, if you do this in a signature, this will cause the
signature to not match.

Other interesting forms of corruption are left as an exercise for the
reader. Amuse yourself by looking at all the text on canonicalization.

This isn't a standards problem. This is an implementation/user problem.
It's all related to the very idea of text mode. Arguably, text mode is a
broken concept. However, it's there for a reason, and that reason is that
there's no global agreement on what constitutes text, and that a binary
transfer of text will *also* cause "data corruption."

So, popping back to your questions, no, we have to have binary mode
signatures, or else PGP/MIME can't sign a binary file cross-platform.

If all parties are using the same rules of what text is, then it doesn't
matter what mode you use, as long as you use the same mode. If you want to
cross a text-rule boundary, you have to use the right mode.

	Jon

Date: Fri, 31 Mar 2000 15:47:56 -0800
To: Ian Bell <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Sender: [email-masked]

>* Is it still possible to use a binary mode signature (I think the

I would think yes. Thomas's comment notwithstanding, if you encrypt and
sign a binary file, you want to use binary mode. If you can't encrypt and
sign a binary file, then PGP/MIME is mostly worthless.

>  this point is CRLF-terminated lines of us-ascii characters?

Maybe. It depends on the semantic comment of the file.

>  use binary mode signatures" in the openPGP/MIME draft?

Consider this to be pretty much the same as text mode VS binary mode in FTP.

If you send a binary file in text mode, you can end up with problems,
depending on what the sender and receiver think constitutes a line end.
This ends up essentially being data corruption and an interoperability
problem. For example, if you send a binary file in text mode from a unix
system to an NT system, then the NT system will replace all 0x10
(pseudo-LFs) with 0x1310 (pseudo-CRLF). If you then pull it back to a unix
system in text mode, this will be undone. But if you transfer it in binary
mode, you have garbage added bytes. If you were really unlucky and you then
got the file in text mode on a Mac, then the 0x1310s will all become 0x13s.

If you send a text file in binary mode, then it might end up on another
system with the wrong flavor of line ends.

Needless to say, if you do this in a signature, this will cause the
signature to not match.

Other interesting forms of corruption are left as an exercise for the
reader. Amuse yourself by looking at all the text on canonicalization.

This isn't a standards problem. This is an implementation/user problem.
It's all related to the very idea of text mode. Arguably, text mode is a
broken concept. However, it's there for a reason, and that reason is that
there's no global agreement on what constitutes text, and that a binary
transfer of text will *also* cause "data corruption."

So, popping back to your questions, no, we have to have binary mode
signatures, or else PGP/MIME can't sign a binary file cross-platform.

If all parties are using the same rules of what text is, then it doesn't
matter what mode you use, as long as you use the same mode. If you want to
cross a text-rule boundary, you have to use the right mode.

	Jon

Date: Fri, 31 Mar 2000 11:51:00 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Sender: [email-masked]

If so,

>Received: by sobolev.rhein.de (Postfix, from userid 200) id 80892F259; Fri, 31 Mar 2000 11:33:36 +0200 (MEST)
Date: Fri, 31 Mar 2000 11:33:36 +0200
From: Thomas Roessler <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Ian Bell <[email-masked]>, [email-masked]
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Message-ID: <[email-masked]>
Mail-Followup-To: Jon Callas <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
References: <[email-masked]> <[email-masked]> <p04310119b509aeced1b2@[172.20.1.38]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.10i
In-Reply-To: <p04310119b509aeced1b2@[172.20.1.38]>; from [email-masked] on Thu, Mar 30, 2000 at 05:27:42PM -0800
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Date: Thu, 30 Mar 2000 17:27:42 -0800
To: Ian Bell <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Sender: [email-masked]

I don't think so.

Clear as mud?

	Jon

>Received: by sobolev.rhein.de (Postfix, from userid 200) id 97704F259; Thu, 30 Mar 2000 14:19:28 +0200 (MEST)
Date: Thu, 30 Mar 2000 14:19:27 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: PGP/MIME interop, new test data
Message-ID: <[email-masked]>
Mail-Followup-To: [email-masked]
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.10i
Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT"
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--ghzN8eJ9Qlbqn3iT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

The script I used to generate the test data triggered a
bug in the PGP version installed here (over-eager addition
of carriage returns, *grrrr*).  I've just uploaded new
test data.

--=20

--ghzN8eJ9Qlbqn3iT
Content-Type: application/pgp-signature
Content-Disposition: inline

--ghzN8eJ9Qlbqn3iT--

>Received: by sobolev.rhein.de (Postfix, from userid 200) id 2BF92F259; Thu, 30 Mar 2000 12:36:07 +0200 (MEST)
Date: Thu, 30 Mar 2000 12:36:06 +0200
From: Thomas Roessler <[email-masked]>
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Message-ID: <[email-masked]>
Mail-Followup-To: Ian Bell <[email-masked]>, [email-masked]
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.10i
In-Reply-To: <[email-masked]>; from [email-masked] on Thu, Mar 30, 2000 at 11:09:56AM +0100
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Date: Thu, 30 Mar 2000 11:09:56 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite.
Sender: [email-masked]

 From RFC2015:

2.  PGP data formats

>Received: by sobolev.rhein.de (Postfix, from userid 200) id F1D62F259; Thu, 30 Mar 2000 00:29:13 +0200 (MEST)
Date: Thu, 30 Mar 2000 00:29:13 +0200
From: Thomas Roessler <[email-masked]>
To: Tom Zerucha <[email-masked]>
Cc: Rodney Thayer <[email-masked]>, [email-masked]
Subject: Re: Zerucha's OPGP?
Message-ID: <[email-masked]>
Mail-Followup-To: Tom Zerucha <[email-masked]>, Rodney Thayer <[email-masked]>, [email-masked]
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.9i
In-Reply-To: <[email-masked]>; from [email-masked] on Wed, Mar 29, 2000 at 04:56:33PM -0500
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Tom,

would you mind to check out
http://cryptome.org/bernstein-bxa.org?  

I think you can now legally make your implementation
accessible to the general public, even outside the United
States, so we can use it as a reference module for some of
the interoperability testing.

Thanks.

Date: Wed, 29 Mar 2000 16:56:33 -0500
From: Tom Zerucha <[email-masked]>
To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
Subject: Re: Zerucha's OPGP?
Sender: [email-masked]

On Wed, Mar 29, 2000 at 05:57:29AM -0800, Rodney Thayer wrote:
> anyone actually found a copy of Zerucha's code lately?  www.cryptography.org
> seens to not have it (an 'opgp', that is)

http://cryptography.org/crypto/[RANDOM]/pgp/palmopgp/

has an openssl version, though it might be a little datd.

http://cryptography.org/crypto/[RANDOM]/pgp/opgp/

has the 0.99x version

If anyone else wants to host it, feel free to do so.

Here is a (OOPS, REVERSED) patch against 0.99x for OpenSSL 0.9.4:

diff -Bbur opgp-1.0a/libopgp.doc opgp99x/libopgp.doc
--- opgp-1.0a/libopgp.doc	Wed Mar 29 16:45:06 2000
+++ opgp99x/libopgp.doc	Mon Aug 24 01:12:01 1998
@@ -1,4 +1,4 @@
-PGPlib 1.00 Free Open PGP toolkit
+PGPlib 1.00 (prerelease) Open PGP toolkit
 
 opgplib is a set of routines designed to implement OpenPGP according to the
 IETF specification using SSLeay and zlib.
@@ -42,8 +42,7 @@
 
 MAIN
 
-opgp is a command line program that allows easy script (batch) access
-for encryption and signature functions within the library.
+opgp is a not-quite compatible version of PGP5.0.
 
 See opgp -q usage for updates, but briefly, opgp without encryption parameters
 will process until it gets text or a literal packet, and thus duplicates most
diff -Bbur opgp-1.0a/opgplib/getkey.c opgp99x/opgplib/getkey.c
--- opgp-1.0a/opgplib/getkey.c	Wed Mar 29 16:44:35 2000
+++ opgp99x/opgplib/getkey.c	Sat Jul 18 00:07:12 1998
@@ -186,7 +186,7 @@
             continue;
           rsatmp->d = PGP_mpiBN(&bp);
           rsatmp->q = PGP_mpiBN(&bp), rsatmp->p = PGP_mpiBN(&bp);
-          BN_mul(temp = BN_new(), rsatmp->q, rsatmp->p, ctx);  /* n=pq? */
+          BN_mul(temp = BN_new(), rsatmp->q, rsatmp->p);  /* n=pq? */
           if (BN_cmp(temp, rsatmp->n) != 0) {
             RSA_free(rsatmp);
             BN_free(temp);
diff -Bbur opgp-1.0a/opgplib/pkdec.c opgp99x/opgplib/pkdec.c
--- opgp-1.0a/opgplib/pkdec.c	Wed Mar 29 16:44:37 2000
+++ opgp99x/opgplib/pkdec.c	Sat Jul 18 00:07:12 1998
@@ -29,13 +29,13 @@
   if (j == 16 || j == 20) {
     u8_t cbuf[1024];            /* size of key */
     BN_CTX *ctx = BN_CTX_new();
-    BIGNUM *a, *b, *c = BN_new();
+    BIGNUM *a, *b, *c;
     DH *dhkey = deckey;
 
     a = PGP_mpiBN(&bp);
     b = PGP_mpiBN(&bp);
     BN_mod_exp(a, a, dhkey->priv_key, dhkey->p, ctx);
-    BN_mod_inverse(c, a, dhkey->p, ctx);
+    c = BN_mod_inverse(a, dhkey->p, ctx);
     BN_mod_mul(a, c, b, dhkey->p, ctx);
     DH_free(dhkey), BN_clear_free(b), BN_clear_free(c), BN_CTX_free(ctx);
     j = BN_bn2bin(a, cbuf);
diff -Bbur opgp-1.0a/opgplib/sigchk.c opgp99x/opgplib/sigchk.c
--- opgp-1.0a/opgplib/sigchk.c	Wed Mar 29 16:44:40 2000
+++ opgp99x/opgplib/sigchk.c	Mon Aug 24 01:13:04 1998
@@ -10,10 +10,10 @@
                       u8_t * hash, int hlen)
 {
   BN_CTX *ctx = BN_CTX_new();
-  BIGNUM *t1 = BN_new(), *t2 = BN_new(), *t3 = BN_new(), *u2 = BN_new();
+  BIGNUM *t1 = BN_new(), *t2 = BN_new(), *t3 = BN_new(), *u2 = NULL;
   int ret;
 
-  BN_mod_inverse(u2, u1, dsakey->q, ctx);
+  u2 = BN_mod_inverse(u1, dsakey->q, ctx);
   BN_bin2bn(hash, hlen, t3);
   BN_mod_mul(t3, t3, u2, dsakey->q, ctx);
   BN_mod_mul(u2, r, u2, dsakey->q, ctx);
diff -Bbur opgp-1.0a/opgplib/sigmak.c opgp99x/opgplib/sigmak.c
--- opgp-1.0a/opgplib/sigmak.c	Wed Mar 29 16:44:41 2000
+++ opgp99x/opgplib/sigmak.c	Mon Aug 24 01:13:04 1998
@@ -62,9 +62,9 @@
     BN_mod_exp(u1, ((DSA *) seckey)->g, u2, ((DSA *) seckey)->p, ctx);
     BN_mod(r, u1, ((DSA *) seckey)->q, ctx);
     /* Compute  u1 = inv(u2) (t2 + xr) mod q */
-    BN_mul(u1, ((DSA *) seckey)->priv_key, r, ctx);
+    BN_mul(u1, ((DSA *) seckey)->priv_key, r);
     BN_add(u1, u1, t2);
-    BN_mod_inverse(t1, u2, ((DSA *) seckey)->q, ctx);
+    t1 = BN_mod_inverse(u2, ((DSA *) seckey)->q, ctx);
     BN_mod_mul(u1, u1, t1, ((DSA *) seckey)->q, ctx);
     DSA_free(((DSA *) seckey));
   } else
diff -Bbur opgp-1.0a/paths.mak opgp99x/paths.mak
--- opgp-1.0a/paths.mak	Wed Mar 29 16:44:27 2000
+++ opgp99x/paths.mak	Mon Jun  8 11:28:33 1998
@@ -1,6 +1,6 @@
 SSLPATH = /usr/local/ssl
 LIBPATH = -L$(SSLPATH)/lib
-INCLUDE = -I$(SSLPATH)/include/openssl -I$(SSLPATH)/include
+INCLUDE = -I$(SSLPATH)/include
 CFLAGS = -Wall $(INCLUDE) -O6 -s
 
 #where to put the files

>Received: by sobolev.rhein.de (Postfix, from userid 200) id 75032F259; Wed, 29 Mar 2000 19:29:05 +0200 (MEST)
Date: Wed, 29 Mar 2000 19:29:05 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: PGP/MIME interop testing: Very first steps towards a test suite.
Message-ID: <[email-masked]>
Mail-Followup-To: Thomas Roessler <[email-masked]>, [email-masked]
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.9i
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Date: Wed, 29 Mar 2000 05:57:29 -0800
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Zerucha's OPGP?
Sender: [email-masked]

anyone actually found a copy of Zerucha's code lately?  www.cryptography.org
seens to not have it (an 'opgp', that is)

Date: Wed, 29 Mar 2000 14:15:52 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Cc: Thomas Roessler <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Mail-Followup-To: [email-masked], Thomas Roessler <[email-masked]>
Sender: [email-masked]

On Wed, 29 Mar 2000, Thomas Roessler wrote:

> >  a) Tom Zerucha's OPGP  (ftp.cryptography.org?)
> 
> Is this, BTW, available outside the United States now?

An unamed person from outside the U.S. sent me a copy some time
ago.  A small problem with 0.99x is that it does not link against
OpenSSL.

-- 
Werner Koch				OpenPGP key 621CC013	
OpenIT GmbH i.G.                        tel   +49 211 465357                           
Birkenstr. 12                           email [email-masked]                             
D-40233 Düsseldorf                      http://www.openit.de

Date: Wed, 29 Mar 2000 14:09:34 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: DRAFT status and Compatibility testing
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 29 Mar 2000, Dave Del Torto wrote:

> I am hoping you'll also implement our two newest drafts, OpenPGP/MIME
> and OpenPGP/MIME Multipart Signatures. Both could be extremely useful
> in a scriptable UNIX GnuPG version.

I'll provide any low level function when needed; however everything
else can be done with a little bit of scripting.

-- 
Werner Koch				OpenPGP key 621CC013	
OpenIT GmbH i.G.                        tel   +49 211 465357                           
Birkenstr. 12                           email [email-masked]                             
D-40233 Düsseldorf                      http://www.openit.de

>Received: by sobolev.rhein.de (Postfix, from userid 200) id EF0FAF259; Wed, 29 Mar 2000 13:45:52 +0200 (MEST)
Date: Wed, 29 Mar 2000 13:45:52 +0200
From: Thomas Roessler <[email-masked]>
To: Dave Del Torto <[email-masked]>
Cc: Werner Koch <[email-masked]>, [email-masked], William H Geiger III <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Message-ID: <[email-masked]>
Mail-Followup-To: Thomas Roessler <[email-masked]>, Dave Del Torto <[email-masked]>, Werner Koch <[email-masked]>, [email-masked], William H Geiger III <[email-masked]>
References: <p04310103b506a93ebb88@[172.20.1.38]> <[email-masked]> <[email-masked]> <p04310120b5079644f148@[192.168.248.7]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.9i
In-Reply-To: <p04310120b5079644f148@[192.168.248.7]>; from [email-masked] on Wed, Mar 29, 2000 at 03:19:54AM -0800
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2000-03-29 03:19:54 -0800, Dave Del Torto wrote:

> I am hoping you'll also implement our two newest
> drafts, OpenPGP/MIME and OpenPGP/MIME Multipart
> Signatures. Both could be extremely useful in a
> scriptable UNIX GnuPG version.

I think that, for Unix use, a perl script based on, say,
the MIME::Tools (3pm) package would be better suited.
Everything else would mean code duplication when GnuPG is
used with any reasonable Mail User Agent which has a
decent MIME parser itself.

>Received: by sobolev.rhein.de (Postfix, from userid 200) id 82D77F259; Wed, 29 Mar 2000 13:28:17 +0200 (MEST)
Date: Wed, 29 Mar 2000 13:28:17 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: DRAFT status and Compatibility testing
Message-ID: <[email-masked]>
Mail-Followup-To: Thomas Roessler <[email-masked]>, [email-masked]
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.9i
In-Reply-To: <[email-masked]>; from [email-masked] on Wed, Mar 29, 2000 at 12:31:35PM +0200
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2000-03-29 12:31:35 +0200, Werner Koch wrote:

>  a) Tom Zerucha's OPGP  (ftp.cryptography.org?)

Is this, BTW, available outside the United States now?

>Received: by sobolev.rhein.de (Postfix, from userid 200) id B70B2F259; Wed, 29 Mar 2000 13:23:54 +0200 (MEST)
Date: Wed, 29 Mar 2000 13:23:54 +0200
From: Thomas Roessler <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: DRAFT status and Compatibility testing
Message-ID: <[email-masked]>
Mail-Followup-To: Thomas Roessler <[email-masked]>, "William H. Geiger III" <[email-masked]>, Jon Callas <[email-masked]>, [email-masked]
References: <p04310103b506a93ebb88@[172.20.1.38]> <[email-masked]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.9i
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Mar 28, 2000 at 02:06:36PM -0600
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2000-03-28 14:06:36 -0600, William H. Geiger III wrote:

> Yes but there is no reason why not to include PGP/MIME
> test data. One can document that this part of the data
> is for a seperate yet related RFC. Most 2440
> applications will also want to be PGP/MIME compliant.

I tend to disagree.  For instance, code signing with
OpenPGP certainly has no use for the PGP/MIME framework.
Additionally, PGP/MIME is essentially just about MIME
encapsulation of PGP messages, so a test suite for this
could be quite restricted, and would mostly have to handle
MIME encoding issues and pitfalls, plus some playing
around with micalg parameters and their effect.

Date: Wed, 29 Mar 2000 03:19:54 -0800
To: Werner Koch <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Cc: [email-masked], William H Geiger III <[email-masked]>
Sender: [email-masked]

At 12:43 pm +0200 2000-03-29, Werner Koch wrote:
>On Tue, 28 Mar 2000, William H. Geiger III wrote:
>
>  > Most 2440 applications will also want to be PGP/MIME compliant.
>
>I don't think so, it is good Unix practise to do layering and MIME is
>something you need in MUAs and not in an encryption tool.

Werner,

I am hoping you'll also implement our two newest drafts, OpenPGP/MIME
and OpenPGP/MIME Multipart Signatures. Both could be extremely useful
in a scriptable UNIX GnuPG version.

I've asked Will Price at PGP Security if they plan to support the
drafts, but I'm not sure they plan to do so. If both were
interoperable, that would of course be ideal. :)

    dave

Date: Wed, 29 Mar 2000 12:43:35 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: DRAFT status and Compatibility testing
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, 28 Mar 2000, William H. Geiger III wrote:

> Most 2440 applications will also want to be PGP/MIME compliant.

I don't think so, it is good Unix practise to do layering and MIME is
something you need in MUAs and not in an encryption tool.  

> The second part would be the "outbound" generation of RFC 2440 packets. We
> should be able to have a set of "skeleton" packets that the tester could
> use for compairison while ignoring the raw data (ie MPI's) that may be

It is not possible to simply compare the packets for a couple of reasons:
You should have random data in it, an implemenation has several 
choices to encode the packet length and and the order of subpackets is 
not regulated.  Doing some clever diffs over the output of a packet   
dumping tools would be possible.  

> different. As an example the application being tested needs to generate a
> v3 RSA public key. The tests could use the "skeleton" test packet to

(OpenPGP implementations SHOULD generate V4 keys (see 5.5.2))

IMHO, tTest scripts are the way to go; this is a lot of work unless we agree
on a common commandline interface and each implementation comes with a
wrapper for this interface.

   Werner

-- 
Werner Koch				OpenPGP key 621CC013	
OpenIT GmbH i.G.                        tel   +49 211 465357                           
Birkenstr. 12                           email [email-masked]                             
D-40233 Düsseldorf                      http://www.openit.de

Date: Wed, 29 Mar 2000 12:31:35 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: DRAFT status and Compatibility testing
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 29 Mar 2000, Lindsay Mathieson wrote:

> Is there a public freeware implementation of rfc 2440 ?

I know these implementations:

 a) Tom Zerucha's OPGP  (ftp.cryptography.org?)
 b) GnuPG (ftp.gnupg.org/gcrypt/gnupg)

I don't know whether PGP 7 is going to implement OpenPGP correctly,
at least they are using deprecated features (pubkey algos 2 and 3).

-- 
Werner Koch				OpenPGP key 621CC013	
OpenIT GmbH i.G.                        tel   +49 211 465357                           
Birkenstr. 12                           email [email-masked]                             
D-40233 Düsseldorf                      http://www.openit.de

Date: Tue, 28 Mar 2000 22:00:37 -0800
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: OpenPGP mailing list <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Sender: [email-masked]

Rodney Thayer wrote:
> 
> I think that products should be built with "test points" in them,
> to allow such things as interoperability testing.  This is how
> we've had to do things in the IPsec and TLS worlds, and in other
> places.  I think we should be able to "dump the keys", and I
> realize that means one
> has to (gasp) have code that reveals the keys.

IPsec and TLS are hundreds of times more complicated to interop test
than OpenPGP should be.  IPsec and TLS are extremely complex, OpenPGP
is fairly straight forward.  Dumping keys is an obscure debug
scenario used to figure out why two implementations do not interop. 
Frankly, I expect the OpenPGP testing will have very few cases of
interop failure, and that such cases will be reasonably explainable
with things like "we didn't implement that optional algorithm."

> On the other hand, if we run in "trust me, it's ok" mode, we're
> degenerating into security by obscurity.  If I were auditing an
> implementation, I'd want to see the keys to validate it myself.

A main part of the point I'm making is that we are NOT auditing
implementations.  This is not a security review for each of our
products.  This is an interop test.  If some other product uses a
session key of 0, it's not the job of the interop tests to discover
that.  If I can read the other guy's messages/keys and he can read
mine, we're set to go.

> Remember, there's nothing stopping someone from revealing the keys
> anyway -- you can't inhibit someone from saving copies of their
> key material, or even publishing it.  So this is a previously
> existing non-problem.

As I said, the tests must be able to be run by any user sitting at
each of our products without debug tools or special code.  Going
beyond that gets into a security review which is not what we're doing
here.

Hal Finney wrote:
> I am inclined to think that traditional interoperability testing is
> a better way to approach this problem.  At least with openpgp we
> don't all have to get together, it can all be done online.
> 
> We would define a specific set of message/key types to create, and
> everyone who wanted to participate would create messages/keys of
> those types (or whatever subset they support), then everyone else
> would try to read them.

Thanks for the correction Hal.  That sounds like an efficient
approach.

- -- Will

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

Date: Tue, 28 Mar 2000 21:23:26 -0800
To: OpenPGP mailing list <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Sender: [email-masked]

I think that products should be built with "test points" in them, to allow
such things as interoperability testing.  This is how we've had to do
things in the IPsec and TLS worlds, and in other places.  I think we
should be able to "dump the keys", and I realize that means one
has to (gasp) have code that reveals the keys.

On the other hand, if we run in "trust me, it's ok" mode, we're degenerating
into security by obscurity.  If I were auditing an implementation, I'd want
to see the keys to validate it myself.

Remember, there's nothing stopping someone from revealing the keys
anyway -- you can't inhibit someone from saving copies of their
key material, or even publishing it.  So this is a previously
existing non-problem.

At 04:25 PM 3/28/00 -0800, Will Price wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Some of the discussion I've seen thus far has gone a bit too far it
>seems.
>
>Proposals such as using pre-determined session keys or other
>low-level crypto items may require ripping apart the software
>packages being subjected to the testing and writing new code in order
>to perform the test.  This is not going to prove anything other than
>the fact that the new code (which isn't necessarily part of the
>product) enabled a piece of software to complete an obscure low-level
>test, and will lengthen the testing cycle from something that could
>be done in a couple of weeks to something that will likely take many
>months to agree upon, design, write, perform testing, repeat.
>
>Any test designed to prove interoperability should adhere stricly to
>the principle that interoperability between OpenPGP products is a
>high-level operation basically limited to the following:
>
>* Public/Private Key import/export
>* Encrypted and/or signed message interop in its various forms
>
>Things like PGP/MIME, and low-level testing of crypto algorithms are
>irrelevant to this task except insofar as they have an effect on the
>above two items (which for instance PGP/MIME does not -- that
>document will require its own separate interop testing).  We're not
>doing a FIPS crypto test on every product here, we're just testing
>interop of the items generated by our common products which apply
>directly to RFC 2440.
>
>Making a test suite of messages and keys which use an array of
>algorithms and variations should be a simple task any user can
>perform sitting at any of our products without rewriting code,
>turning on debug features, recompiling, etc...
>
>This set of data would be termed the OpenPGP Compatibility Suite, and
>each vendor could perform the testing on their own product, submit
>that to the list, and any other vendor could use that same data to
>verify the results.
>
>- -- Will
>
>Will Price, Director of Engineering
>PGP Security, Inc.
>a division of Network Associates, Inc.
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 7.0 (Build 144 Alpha)
>
>iQA/AwUBOOFNMKy7FkvPc+xMEQJtdQCfTzZrTm9faAlZRfrgpSGfQjEbrqcAniGR
>9NHfkzlUee6nCdrK+Nr/DrIO
>=5URX
>-----END PGP SIGNATURE-----

Date: 29 Mar 2000 3:2:33 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
To: [email-masked]
Sender: [email-masked]

Is there a public freeware implementation of rfc 2440 ?
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.8 Preview 4, on March 29, 2000, in Win95
4.10
	http://www.blackpaw.com/

From: [email-masked]
Date: Tue, 28 Mar 2000 18:31:30 -0800
To: [email-masked]
Subject: Re: DRAFT status and Compatibility testing
Sender: [email-masked]

The problem with a "test suite" is that it would allow a software creator
to test that his software READS openpgp compliant data, but not that it
CREATES compliant data.  The latter testing is more difficult because as
Jon Callas pointed out there is a lot of randomness in what is created
and so you can't just compare against a "known good" output.

I am inclined to think that traditional interoperability testing is a
better way to approach this problem.  At least with openpgp we don't all
have to get together, it can all be done online.

We would define a specific set of message/key types to create, and
everyone who wanted to participate would create messages/keys of those
types (or whatever subset they support), then everyone else would try
to read them.

See the S/MIME page at
http://www.rsasecurity.com/standards/smime/interop_center.html for an
example.  They did it differently by comparing with a reference
implementation, but since we have only a few implementations I think
it is feasible to have N by N comparisons.

Hal Finney

Date: Tue, 28 Mar 2000 16:25:12 -0800
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: John W Noerenberg II <[email-masked]>, OpenPGP mailing list <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Sender: [email-masked]

Some of the discussion I've seen thus far has gone a bit too far it
seems.

Proposals such as using pre-determined session keys or other
low-level crypto items may require ripping apart the software
packages being subjected to the testing and writing new code in order
to perform the test.  This is not going to prove anything other than
the fact that the new code (which isn't necessarily part of the
product) enabled a piece of software to complete an obscure low-level
test, and will lengthen the testing cycle from something that could
be done in a couple of weeks to something that will likely take many
months to agree upon, design, write, perform testing, repeat.

Any test designed to prove interoperability should adhere stricly to
the principle that interoperability between OpenPGP products is a
high-level operation basically limited to the following:

* Public/Private Key import/export
* Encrypted and/or signed message interop in its various forms

Things like PGP/MIME, and low-level testing of crypto algorithms are
irrelevant to this task except insofar as they have an effect on the
above two items (which for instance PGP/MIME does not -- that
document will require its own separate interop testing).  We're not
doing a FIPS crypto test on every product here, we're just testing
interop of the items generated by our common products which apply
directly to RFC 2440.

Making a test suite of messages and keys which use an array of
algorithms and variations should be a simple task any user can
perform sitting at any of our products without rewriting code,
turning on debug features, recompiling, etc...

This set of data would be termed the OpenPGP Compatibility Suite, and
each vendor could perform the testing on their own product, submit
that to the list, and any other vendor could use that same data to
verify the results.

- -- Will

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

Date: Wed, 29 Mar 2000 09:34:46 +0930
To: "William H. Geiger III" <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Cc: OpenPGP mailing list <[email-masked]>, "Jeffrey I. Schiller" <[email-masked]>
Sender: [email-masked]

At 10:03 AM -0600 3/28/00, William H. Geiger III wrote:
>
>IMHO what we need to do is put together a suite of test data that conforms
>to RFC 2440.

Sounds like a good idea.  We'll need some data and specifications on 
what the data tests.  The message I proposed isn't an exhaustive 
test.  But at least it demonstrates some level of interoperability. 
That's a first step.  Are you volunteering to write the specs and 
build the test data?

>
>Additionally data sets should be divided into MUST, SHOULD, and OPTIONAL
>catagories.

First step here is to create the matrix I have in mind a la 1123.

>
>Testing should be done to see if the products are able to generate &
>process the various packet types.
>
>Some of the non-RFC2440 packets should be included (X.509, PhotoID,
>...ect) so vendors can test that their software can properly handle
>non-RFC2440 packets without crashing (this has been a problem with the pks
>software).

We can bear that in mind.  It certainly has impact on what we do.  If 
there are non-2440 packets we need to consider, I'd entertain the 
idea of an new draft to incorporate them into 2440's successor.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   But now I know our world is no more permanent
   than a wave rising on the ocean.
   -- Arthur Golden, "Memoirs of a Geisha", 1997
   ----------------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 28 Mar 2000 14:06:36 -0600
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: DRAFT status and Compatibility testing
Sender: [email-masked]

In <p04310103b506a93ebb88@[172.20.1.38]>, on 03/28/00 
   at 12:51 PM, Jon Callas <[email-masked]> said:

>I think this is an excellent idea. 2440 is a data format standard, and
>consequently, the test suite mostly should consist of data. The only real
>comment I have on your list is that PGP/MIME isn't part of 2440, it's a
>separate RFC. (And in my opinion, this is a feature, not a bug. It's
>called layering.)

Yes but there is no reason why not to include PGP/MIME test data. One can
document that this part of the data is for a seperate yet related RFC.
Most 2440 applications will also want to be PGP/MIME compliant.

>There's a related issue that I want to bring up, though.

Well I see the testing of the application as 2 part. The 1st part would be
the "inbound" processing of RFC 2440 packets. I don't see any risks
involved with using a fixed data set for this part of the testing.

The second part would be the "outbound" generation of RFC 2440 packets. We
should be able to have a set of "skeleton" packets that the tester could
use for compairison while ignoring the raw data (ie MPI's) that may be
different. As an example the application being tested needs to generate a
v3 RSA public key. The tests could use the "skeleton" test packet to
compair that all of the parts are generated and formated properly while
ignoring that data contained in MPI(1) and MPI(2) is different.

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

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

Date: Tue, 28 Mar 2000 10:51:09 -0800
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Sender: [email-masked]

In our last episode ("Re: DRAFT status and Compatibility testing", shown on
3/28/00), William H. Geiger III said:

>IMHO what we need to do is put together a suite of test data that conforms
>to RFC 2440.
>

[...]

>Some of the non-RFC2440 packets should be included (X.509, PhotoID,
>...ect) so vendors can test that their software can properly handle
>non-RFC2440 packets without crashing (this has been a problem with the pks
>software).
>

I think this is an excellent idea. 2440 is a data format standard, and
consequently, the test suite mostly should consist of data. The only real
comment I have on your list is that PGP/MIME isn't part of 2440, it's a
separate RFC. (And in my opinion, this is a feature, not a bug. It's called
layering.)

There's a related issue that I want to bring up, though.

Many messages, when generated require random numbers to be used. In a
non-security environment, we'd have no objections to saying, "Here are the
inputs, here is the final data, make sure you generate this." Do we have an
objection to saying, "With a session key of K, encrypt message M, and your
result should look like R"? I don't -- I consider this to be the equivalent
of a crypto test vector. On the other hand, it still gives me a small
shudder, and I think this is one of those things on which gentlepersons can
disagree. An alternative is to come up with a test suite where an
implementation generates a message with known keys, and then writes out the
session keys and signature randoms, so that they can be verified. But on
this one, I don't see it's any better.

The problem, as I see it, is that if an implementation has a test mode in
which a random can be specified, then that's potentially a way to create a
hacked version with bad or known keys. But on the other hand, if an
implementation has a test mode in which the randoms can be leaked, then
that's a way to make a hacked version with a covert channel. If I have to
pick between one of those risks, I pick the former.

On the third hand, if we just say "non serviam" to that, then we run the
risk that a hacked version could pass all compliance tests and no one would
know otherwise. I don't like measuring compliance when we aren't specifying
the inputs, either.

I think my opinion (yes, I'm tentative here) is that 2440 is a data format
standard. We already have been wise enough to not get it into the whole
mess of crypto engineering in it. Our goal in advancing this is to make
sure that given a set of inputs, an implementation produces the proper
results. Those inputs may be finished messages that must be decoded, or
they may be plaintext, ciphers, randoms, etc. that should generate a fixed
message. There's an engineering problem in making an implementation
testable and secure. But that's a problem that the implementors have to
solve.

Opinions?

	Jon

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 28 Mar 2000 10:03:59 -0600
To: John  W Noerenberg II <[email-masked]>
Cc: OpenPGP mailing list <[email-masked]>, "Jeffrey I. Schiller" <[email-masked]>
Subject: Re: DRAFT status and Compatibility testing
Sender: [email-masked]

In <a04310101b5059c6165cd@[169.208.192.29]>, on 03/27/00 
   at 06:41 PM, John  W Noerenberg II <[email-masked]> said:

>Towards 1, I propose the following:  We'll exchange encrypted, signed 
>objects exercising the various modes described in 2440.  I'll keep 
>score, and publish the results for the WG.  To participate, send me a 
>note with subject:

IMHO what we need to do is put together a suite of test data that conforms
to RFC 2440.

Envelope
--------

Ascii-armor
PGP/MIME

Algorithms
----------

Compresion
Symetric encryption
Public Key encryption
Hash

Signatures
----------

Signature Types
Version 3
Version 4
    -- Hashed Subpackets
    -- Non-Hashed Subpackets

Keys
----

Private Keys
Public Keys
    Version 3
    Version 4
        -- Subkeys
    
(NOTE: This is not a complete list)

Additionally data sets should be divided into MUST, SHOULD, and OPTIONAL
catagories.

Testing should be done to see if the products are able to generate &
process the various packet types.

Some of the non-RFC2440 packets should be included (X.509, PhotoID,
...ect) so vendors can test that their software can properly handle
non-RFC2440 packets without crashing (this has been a problem with the pks
software).

IIRC someone had a partal data set available but I do not know if it is
still around nor if it has been updated.

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

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

Date: Tue, 28 Mar 2000 09:41:01 +0930
To: OpenPGP mailing list <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: DRAFT status and Compatibility testing
Cc: "Jeffrey I. Schiller" <[email-masked]>
Sender: [email-masked]

We've talked about moving 2440 to DRAFT for a while now.  We need to 
do this.  There are really two things we need: 1) two interoperable 
implementations, and 2) verification of the requirements of the 
protocol.  Even though we're not meeting in Adelaide, I thought 
kicking off some interoperability testing during the week would be an 
IETF'ish thing to do.

Towards 1, I propose the following:  We'll exchange encrypted, signed 
objects exercising the various modes described in 2440.  I'll keep 
score, and publish the results for the WG.  To participate, send me a 
note with subject:

	OpenPGP Compatibility Test 1

with directions on where to find a public key you'd like me to use. 
I will send an object encrypted with the keys I have and signed with 
mine on Thursday, Mar 30, 1500+930, at the conclusion of the SAAG 
meeting.

When you receive the message, decrypt the object, validate the 
signature, and send me back the results signed with your key.  Your 
response needs to include: the plaintext, what algorithms were used 
and evidence you've validated my signature.  My key is available on 
the MIT key server.

For 2, we'll need to build a compliance matrix to verify that all the 
required elements of 2440 have been treated (or not).  If we find 
features that have not been used, or are disputed, I will propose 
eliminating them unless resolution is desired, and found.  I'll start 
on 2, but I'll be looking for help.

Remember, the subject of the message is: OpenPGP Compatibility Test 
1.  I'm filtering messages by the subject to get your entry.  If you 
don't use this subject, I might miss you.

The message will go out at the end of the SAAG meeting on Thursday.

best,

-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   But now I know our world is no more permanent
   than a wave rising on the ocean.
   -- Arthur Golden, "Memoirs of a Geisha", 1997
   ----------------------------------------------------------------------

Date: Wed, 22 Mar 2000 08:17:43 -0500
To: Recipient List Suppressed:;
From: Robert Guerra <[email-masked]>
Subject: Fwd: [PGP-Discussion] PGP-Users List is Operational
Sender: [email-masked]

- --- begin forwarded text

Date: Wed, 22 Mar 2000 06:48:50 -0600
From: [email-masked]
Subject: [PGP-Discussion] PGP-Users List is Operational

From: [email-masked]

       Hello everyone,
Dave Del Torto has announced that the new, permanent
PGP Users list is officially open.
This is the list that he and Fred were working on setting up
when Fred disappeared.
To find out more, including how to subscribe go to:

<http://cryptorights.org/pgp-users/>http://cryptorights.org/pgp-users/

                   Chuck in Missouri

Date: Sat, 18 Mar 2000 14:17:05 -0500
To: [email-masked]
From: Robert Guerra <[email-masked]>
Subject: CFP2000 Conference - PGP Keysigning Session
Sender: [email-masked]

Hi:

I'll be attending the CFP2000 conference being held in Toronto the 
first week in April. If you are attending also, I'd like to extend an 
invitation to participate in the conference pgp keysigning I am 
organizing

The conference is shaping up to be one of the primier meetings of the year and
presents a unique opportunity not only personally meet the numerous 
key people in the field but also to extend and interweave the 
existing pgp global web of trust. I've set-up a web page 
(http://pgp.greatvideo.com) which i'll be updating latter this week 
with details on and about the numerous formal & informal web of 
trust/keysigning which i'll be organizing.

If you attending the conference, I look forward to meeting you. If 
you'd like to exchange pgp signatures, but can't make the keysigning 
please let me know so I might be able to meet you ay another time.

Yours Sincerely,

-- 
---
Robert Guerra <[email-masked]>
WWW Page <http://www.cryptorights.org>