headers
Robert Guerra | 18 Mar 2000 20:17

CFP2000 Conference - PGP Keysigning Session


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 <rguerra <at> cryptorights.org>
WWW Page <http://www.cryptorights.org>
Permalink | Reply | 0 comments |
headers
Robert Guerra | 22 Mar 2000 14:17
Picon
Favicon

Fwd: [PGP-Discussion] PGP-Users List is Operational


--- begin forwarded text

Date: Wed, 22 Mar 2000 06:48:50 -0600
From: Chuck44 <at> goin.missouri.org
Subject: [PGP-Discussion] PGP-Users List is Operational

From: Chuck44 <at> goin.missouri.org

       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
Permalink | Reply | 0 comments |
headers
John W Noerenberg II | 28 Mar 2000 02:11

DRAFT status and Compatibility testing

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.
(Continue reading)

Permalink | Reply | 12 comments |
headers
William H. Geiger III | 28 Mar 2000 18:03

Re: DRAFT status and Compatibility testing

In <a04310101b5059c6165cd <at> [169.208.192.29]>, on 03/27/00 
   at 06:41 PM, John  W Noerenberg II <jwn2 <at> qualcomm.com> 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
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jon Callas | 28 Mar 2000 20:51
Gravatar

Re: DRAFT status and Compatibility testing

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
William H. Geiger III | 28 Mar 2000 22:06

Re: DRAFT status and Compatibility testing

In <p04310103b506a93ebb88 <at> [172.20.1.38]>, on 03/28/00 
   at 12:51 PM, Jon Callas <jon <at> callas.org> 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
John W Noerenberg II | 29 Mar 2000 02:04

Re: DRAFT status and Compatibility testing

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

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Will Price | 29 Mar 2000 02:25
Gravatar

Re: DRAFT status and Compatibility testing


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
hal | 29 Mar 2000 04:31

Re: DRAFT status and Compatibility testing

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
Permalink | Reply | 0 comments |
headers
Lindsay Mathieson | 29 Mar 2000 05:02
Picon
Picon

Re: DRAFT status and Compatibility testing

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/
Permalink | Reply | 501 comments |

Gmane