Re: OpenPGP Minutes / Quick Summary

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