Last Modified: 2005-02-10
|Done||Submit Internet-Draft for PGP Key Format & Message Specification|
|Done||Submit Internet Draft for MIME encapsulation of PGP Messages Specification|
|Done||Issue WG Last Call for PGP Key Format & Message Specification Internet-Draft documents|
|Done||Submit PGP Key Format & Message Specification Internet-Draft to IESG for consideration as a Proposed Standard.|
|Done||WG Last Call for PGP/MIME draft|
|Done||Submit PGP/MIME draft to IESG for consideration as PROPOSED standard|
|May 01||Submit Multiple Sig draft to IESG for consideration as PROPOSED standard|
|Jul 01||Begin RFC2440, PGP/MIME Interoperability testing|
|Aug 01||Request DRAFT status for RFC2440|
|RFC2440||PS||OpenPGP Message Format|
|RFC3156||PS||MIME Security with OpenPGP|
Open PGP Minutes
- Chair Derek Atkins
- Tues March 8 2005
1. Agenda Bashing - none
2. AD - Sam Hartman -
Sam requested time on the agenda to discuss a proposed new work item for this working group. The Lemonade group is looking at doing e-mail type operations in some new service environments. One type of environment that they are looking at is low bandwidth devices (such as cell phones) where different types of operations might be desirable. Examples of such operations might be to distill or use incremental download of messages for display on the device.
Currently the issues of end-to-end security have been avoided by the Lemonade group. Open PGP and S/MIME are the two different secure messaging work groups in the IETF and the Lemonade group would like to get guidance and help from the two groups about different ways of providing end-to-end security within the lightweight receivers.
One possible method of dealing with the problem is to require that the server be a recipient on the message. No desirable in some circumstances because the server cannot be trusted. A second method is to require the device to deal with secure messages. This is beyond the capabilities of some devices. The current method under exploration would be to allow the server to extract a correct encrypted key blob, send it to the device for decryption, and then the server would decrypt the bulk message and process it for display.
Glen Parsons (co-chair of the Lemonade group) stated that in addition guidance was desired on some of the security issues the server would need to deal with. An example would be how long should a server keep the decrypted message in a cache for processing, as oppose to decrypting the message each time a new section of the document was desired by the display device.
One proposed method of dealing with this might be to look at the device as a cryptographic module and just implement normal PGP on the server. This would need to be looked at further.
3. Draft-ietf-openpgp-rfc2440bis status
The document editor did not provide a presentation for the meeting. There has not been a recent update of the document, however there has been substantial activity on the list recently which has solve several open issues. The following open issues still remain:
Editorial type changes that will probably just be accepted by the editor
- V2 PKESK advice is not correct (Dave Shaw)
- Call V4 V4 (Dave Shaw)
Two cryptographic issues that need to be looked at:
- CFB "Broken"
Researches have presented a break of CFB where about 25% of the message can be obtained using a fairly small work load under some circumstances. Details of the attack can be found at:
- SHA-1 "Broken"
There have been several recently announced attacks against SHA-1. The biggest result was one of lowering the work of finding a duplicate hash from 2^80 to 2^69. Still a substantial work factor. Sam stood up and said that the issue will be discussed at the SAAG meeting on Thursday, but the current advice from the ADs is not to panic yet. They are searching for a unified method of dealing with the problem along with the question of whether the new longer SHA algorithms are going to be affected as well.
3. PFS - Presenter was not present in the room.