Subject: Re: OpenPGP Minutes / Quick Summary

From: <[email-masked]>
Date: Fri, 14 Jul 2006 13:49:33 -0400

On Fri, 14 Jul 2006 10:02:42 -0400 Ian G <[email-masked]> 
wrote:

>There are probably 10 implementations out
>there...  Of the implementations I know:
>
>Gpg, PGP Inc,
>Cryptix, epointsystems, hushmail

here are some others:

Crypt::OpenPGP - Pure-Perl OpenPGP implementation
http://www.stupidfool.org/perl/docs/perldoc/Crypt/OpenPGP.html

5 pgp products by this company:
http://www.articsoft.com/products.htm

filecrypt (4 pgp products)
http://www.veridis.com/openpgp/en/index.asp

another commercial one here:
http://www.anidirect.com/products/encryption/edge.html

p5-Crypt-OpenPGP
http://www.freebsdsoftware.org/security/p5-Crypt-OpenPGP.html

SharpPrivacy - OpenPGP for C#
http://www.codeproject.com/csharp/sharpprivacy.asp?df=100&forumid=15
716&exp=0&select=519463

a list of members of open pgp alliance:
http://www.openpgp.org/members/

Cryptocx v6 
http://www.easybyte.com/products/cryptocx.html

BPG: An OpenPGP Privacy Toolkit for NetB
http://netbsd-soc.sourceforge.net/projects/bpg/

zendit,  edge
http://www.authora.com/

maybe the implementors of these programs,
and other interested parties who may not be able to travel too far 
away,
could attend future meetings
by videoconferencing of some sort

fwiw,

not a day goes by where i don't use an open pgp product
(besides hushmail ;-) )
for e-mail encryption, file encryption, etc.

and am sure there are many others in similar circumstances,

and we are all very happy that there is an open pgp standard 
that is by and large reasonably adhered to,
and that we can all communicate securely

please keep up the good work,

and

THANKS!!!

vedaal

Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485

---

From: [email-masked] (Daniel A. Nagy)
Date: Sat, 15 Jul 2006 07:15:49 +0200

There is yet one more that I am aware of: mcrypt implements symmetric
encryption and decryption, OpenPGP-style (among other things).

Also, there is openCT, which is an OpenPGP C library on top of gcrypt. I
think, it has not been maintained for a while, but it exists.

Indeed, there are great many OpenPGP implementations.

-- 
Daniel

---

From: Jon Callas <[email-masked]>
Date: Wed, 19 Jul 2006 13:44:13 -0700

Let me talk out of both sides of my mouth for a moment.

On the one hand, it wouldn't be so bad for us. Closing a working  
group is not a sign of failure. Failure is being the committee that  
never ends, and that's a sort of Sartrean, No Exit sort of failure.  
If we don't have work to do, it makes sense to move on and  
reconstitute the group later when we need to.

On the other hand, I think there *is* work still on the table, and  
there are still people interested in doing it. Additionally, this is  
a reasonably coherent group. In general, we pretty much agree on  
direction, even not if in specific details. If anything, we just need  
to make sure that we genuinely have a *need* for an in-person  
meeting. It is a sign of success, not failure, to be able to get all  
the working group's work done on the mailing list.

There is a tendency in the IETF to request in-person meetings with  
progress, when it could be argued that the opposite is true, that the  
need for a meeting is an indication of bad communication in email.

The real message for us, I believe, is that we shouldn't request a  
meeting unless we know that it is needed. If only nine people are  
going to show up, then we shouldn't have the meeting.

Here is an incomplete list of things that I think are still on the  
table:

* PFS draft. I want to see this get to RFC. I have always liked it,  
and think it is useful for a lot of non-email applications.

* Additions for symmetric ciphers. There are a number of symmetric  
ciphers that people have desires for. Primarily, these are national  
ciphers like Camillia, SEED, and GOST. An advantage of OpenPGP is  
that it is easy to make ciphers optional even in implementation. The  
cipher selection algorithm makes it easy for those who want to ignore  
such ciphers to do so. There is a small amount of hair in this in the  
some systems may want hash algorithms as well.

* V5 keys. Many of us have discussed updating the basic public key  
format. I'm possibly guilty of starting this. I'm genuinely torn,  
however, because while I would like to tidy some things up, when I  
ask myself if I'd toss out my existing key for a new one, the answer  
is a resounding no. The biggest argument I can think of against it is  
that it means more for a minimal implementation to implement.

* Data encryption update. It would be nice to update the symmetric  
encryption packet. We could upgrade the MDC into an HMAC. We could  
consider shifting to CBC mode. Like V5 keys, it's easy to argue  
against this on grounds of minimalism.

* Algorithm migration. Should we do more to encourage migration from  
SHA-1 to SHA-256? Should we encourage migration from 3DES to AES?

* Interop cookbook. It would be desirable to have an RFC with  
examples of OpenPGP objects as a help to implementers. This would  
have, for example, an Alice key, a Bob key, and examples of different  
other objects. A message encrypted to Alice and signed by Bob with  
MDC packet, another with non-MDC; Bob's key signed by Alice; and so on.

* OpenPGP/MIME work. We have issues with OpenPGP/MIME and  
interoperability with it. Note that this isn't a uniquely OpenPGP  
problem. The problem is in security multiparts in general. If you  
take a multipart message and want to add encryption, signing, or both  
to it, there is no good way to know how to construct the parts so  
that you'll get the thing to render correctly when you're done. We  
could easily punt this, but we could just as easily tackle it.

To sum up, I think we need to go through this list (and see what else  
someone might have) and use that as a metric. Some of the tasks I  
have there lend themselves neatly to individual submissions. Adding  
in a new cipher can be as simple as getting a number assigned. That's  
a perfect three-page RFC. At the other end of the scale, tidying up  
OpenPGP/MIME means coming up with a profile of an existing standard.

	Jon

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 19 Jul 2006 14:08:24 -0700

On 2006-07-19 13:44:13 -0700, Jon Callas wrote:

> interoperability with it. ... At the other end of the scale,
> tidying up OpenPGP/MIME means coming up with a profile of an
> existing standard.

So, the current OpenPGP/MIME spec is already relatively strict
and actually takes away some of the degrees of freedom that the
original PGP/MIME left open.  Would you care to elaborate a bit
more about what points you'd like to clean up?

Thanks,
-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.

---

From: "Brian G. Peterson" <[email-masked]>
Date: Wed, 19 Jul 2006 18:02:16 -0500

> more about what points you'd like to clean up?

Look back a ways in the archives to the various tabled discussions on 
OpenPGP/MIME and the other variants (inline/partitioned) for email.  I 
remember significant issues being discussed around offline signature 
verification on binary attachments, signatures on signatures (chain of 
evidence), and interoperability issues on the layout of MIME parts.

All of the issues that I mentioned above from memory are issues that are 
directly important to me that I would be participating heavily in working 
on fixing.  This working group correctly tabled a lively discussion on 
some of these issues over a year ago to focus on getting 2440bis 
finalized.

Regards,

   - Brian

---

From: Cat Okita <[email-masked]>
Date: Wed, 19 Jul 2006 19:19:03 -0400 (EDT)

On Wed, 19 Jul 2006, Jon Callas wrote:
> The real message for us, I believe, is that we shouldn't request a meeting 
> unless we know that it is needed. If only nine people are going to show up, 
> then we shouldn't have the meeting.

I'd also be curious to know how closely poor attendance and scheduled
time correlate.  The 18:50 - 19:50 slot didn't seem well attended for
most groups.

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 20 Jul 2006 15:14:57 +1200

Jon Callas <[email-masked]> writes:

>On the one hand, it wouldn't be so bad for us. Closing a working group is not
>a sign of failure. Failure is being the committee that never ends

That would be PKIX then :-).

Peter.

---

From: Jon Callas <[email-masked]>
Date: Thu, 20 Jul 2006 11:33:09 -0700

> some of these issues over a year ago to focus on getting 2440bis

Thanks.

That's basically it.

I wrote down all the things I could remember that we'd said we'd talk  
about later. It's quite possible or even reasonable that for any (or  
all) of these that the WG would decide we're not interested, or that  
an individual submission is just fine.

	Jon