From: Fisher Mark <fisherm@tce.com>
Date: Fri, 16 Oct 1998 02:10:44 +0800
To: "'cypherpunks'" <cypherpunks@cyberpass.net>
Subject: FW: Protocol Action: OpenPGP Message Format to Proposed Standard
Message-ID: <2C396693FBDED111AEF60000F84104A721C01F@indyexch_fddi.indy.tce.com>
MIME-Version: 1.0
Content-Type: text/plain



> From: 	The IESG[SMTP:iesg-secretary@ietf.org]
> Sent: 	Thursday, October 15, 1998 10:27 AM
> Cc: 	RFC Editor; Internet Architecture Board; ietf-open-pgp@imc.org
> Subject: 	Protocol Action: OpenPGP Message Format to Proposed Standard
> 
> 
> 
> The IESG has approved the Internet-Draft 'OpenPGP Message Format'
> <draft-ietf-openpgp-formats-08.txt> as a Proposed Standard.  This
> document is the product of the An Open Specification for Pretty Good
> Privacy Working Group.
> 
> The IESG contact persons are Jeffrey Schiller and Marcus Leech.
> 
> 
>  
> Technical Summary
>  
>   This document defines the formats used by "Phil's Pretty Good
>   Privacy" otherwise known as PGP.
> 
> Working Group Summary
> 
>   After serious discussion the working group came to consensus on this
>   document.
> 
> Protocol Quality
> 
>   The formats used here are the result of a second generation 
>   engineering effort to define an efficient, one pass format for
>   representing information encrypted or signed with PGP. They were
>   reviewed by Jeffrey I. Schiller for the IESG.
> 
> 
> Note to RFC Editor: Please add the following as an IESG Note:
> 
>    This document defines many tag values, yet it doesn't describe a
>    mechanism for adding new tags (for new features). Traditionally the
>    Internet Assigned Numbers Authority (IANA) handles the allocation of 
>    new values for future expansion and RFCs usually define the procedure 
>    to be used by the IANA.  However there are subtle (and not so subtle)
>    interactions that may occur in this protocol between new features and
>    existing features which result in a significant reduction in over all
>    security. Therefore this document does not define an extension
>    procedure. Instead requests to define new tag values (say for new 
>    encryption algorithms for example) should be forwarded to the IESG
>    Security Area Directors for consideration or forwarding to the
>    appropriate IETF Working Group for consideration.
> 
> 
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
fisherm@indy.tce.com          Indianapolis, IN
"Their walls are built of cannon balls, their motto is
'Don't Tread on Me'"