Re: OpenPGP-MIME-Draft

[Thomas Roessler <[e-mail]>]

On 2000-02-17 17:36:50 -0500, [e-mail] wrote:

> Regarding the 2 listed text variants near the beginning of
> section 5 (about the "micalg" parameter), I can live with either
> of them.

I'd greatly prefer var1, since the set of MIC algorithms to be used
is completely determined by the OpenPGP spec.  There is no reason
whatsoever to send OpenPGP/MIME messages with MIC algorithms not
known to OpenPGP.

-- 
http://www.guug.de/~roessler/





Received: by ns.secondary.com (8.9.3/8.9.3) id AAA05506 for ietf-openpgp-bks; Fri, 18 Feb 2000 00:37:26 -0800 (PST)
Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA05502 for <[e-mail]>; Fri, 18 Feb 2000 00:37:23 -0800 (PST)
Received: by postfix.rhein.de (Postfix, from userid 5) id 4B2DB12852; Fri, 18 Feb 2000 09:40:32 +0100 (MET)
>Received: by sobolev.rhein.de (Postfix, from userid 200) id 95C09F14D; Fri, 18 Feb 2000 09:33:00 +0100 (MET)
Date: Fri, 18 Feb 2000 09:33:00 +0100
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP-MIME-Draft
Message-ID: <[e-mail]>
Mail-Followup-To: Thomas Roessler <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.1.4i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Feb 17, 2000 at 05:36:50PM -0500
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2000-02-17 17:36:50 -0500, [e-mail] wrote:

> Regarding the 2 listed text variants near the beginning of
> section 5 (about the "micalg" parameter), I can live with either
> of them.

I'd greatly prefer var1, since the set of MIC algorithms to be used
is completely determined by the OpenPGP spec.  There is no reason
whatsoever to send OpenPGP/MIME messages with MIC algorithms not
known to OpenPGP.

-- 
http://www.guug.de/~roessler/




Received: by ns.secondary.com (8.9.3/8.9.3) id OAA03817 for ietf-openpgp-bks; Thu, 17 Feb 2000 14:33:53 -0800 (PST)
Received: from spamraaa.compuserve.com (as-img-rel-1.compuserve.com [149.174.217.142]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03813 for <[e-mail]>; Thu, 17 Feb 2000 14:33:51 -0800 (PST)
From: [e-mail]
Received: (from mailgate@localhost) by spamraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.2) id RAA16017 for [e-mail]; Thu, 17 Feb 2000 17:36:58 -0500 (EST)
Received: from 212.211.66.15 (fra-pci-lag-vty15.as.wcom.net [212.211.66.15]) by spamraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.2) with SMTP id RAA15981 for <[e-mail]>; Thu, 17 Feb 2000 17:36:50 -0500 (EST)
Date: Thu, 17 Feb 2000 17:36:50 -0500 (EST)
Message-Id: <[e-mail]>
Subject: Re: OpenPGP-MIME-Draft
Apparently-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

When reading "draft-ietf-openpgp-mime-00.txt", I noted 3 typos:

section "2. OpenPGP data formats", 6th line: "to be able _to_
  extract and use ..." [insert "to" before "extract"]

section "3. Content-Transfer-Encoding restrictions", 8th line:
  "(8-bit data MUST be encoded ..." [remove the blank between
  "8-" and "bit"]

section "5. OpenPGP signed data", 1st line of the Note before the
  Example message near the end of the section: "Note: The
  accepted ... convention is ... to end _with_ a <CR><LF>
  sequence." [insert "with" (or "on") between "end" and "a"]

Regarding the 2 listed text variants near the beginning of
section 5 (about the "micalg" parameter), I can live with either
of them.

- Wolfgang Redtenbacher

-----------------------------------------------------------------
Redtenbacher Software            Tel.:   [phone]
Roemerstr. 11/1                  Fax:    [phone]
D-71272 Renningen                e-mail: [e-mail]
-----------------------------------------------------------------



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20210 for ietf-openpgp-bks; Tue, 15 Feb 2000 03:30:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20206 for <[e-mail]>; Tue, 15 Feb 2000 03:30:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22121; Tue, 15 Feb 2000 06:33:33 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-mime-00.txt
Date: Tue, 15 Feb 2000 06:33:33 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-00.txt
	Pages		: 12
	Date		: 14-Feb-00
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  A web site containing an
archive of the list can be found at <http://www.imc.org/ietf-
openpgp>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-mime-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-mime-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-mime-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-mime-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id VAA09819 for ietf-openpgp-bks; Mon, 14 Feb 2000 21:30:14 -0800 (PST)
Received: from pub.jlonline.com ([202.102.24.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09809 for <[e-mail]>; Mon, 14 Feb 2000 21:30:02 -0800 (PST)
Received: from yy ([202.102.66.113]) by pub.jlonline.com (Netscape Messaging Server 4.05) with SMTP id FPYHK601.LCL for <[e-mail]>; Tue, 15 Feb 2000 13:21:42 +0800 
Date: Sun, 28 Mar 1999 18:42:36 +0800
From: caiboyx <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Fw: Automated response from IMC Autoresponder <[e-mail]>
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA09816
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

ÄúºÃ£¡

*******ÏÂÃæÊÇת·¢µÄÓʼþ*****
This mailing list has moved. To send mail to the list, send to:
     [e-mail]
(note the lack of the second dash in the name). This list move
was caused by the large amount of spam being received by the old
mailing list.

If you have any questions, please send them to [e-mail].
*****ת·¢ÄÚÈݽáÊø*****



                    ÖÂ
Àñ£¡

            caiboyx
            [e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id CAA08153 for ietf-openpgp-bks; Fri, 11 Feb 2000 02:34:18 -0800 (PST)
Received: from pharos.hsp.de (pharos.hsp.de [194.77.127.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08149 for <[e-mail]>; Fri, 11 Feb 2000 02:34:16 -0800 (PST)
Received: (from uucp@localhost) by pharos.hsp.de with UUCP id LAA14683 for [e-mail]; Fri, 11 Feb 2000 11:33:00 +0100
Received: from (frodo.gnupg.de) [194.231.77.148] (mail) by beren.gnupg.de with esmtp (Exim 1.92 #1 (Debian)) id 12JDF3-0007P5-00; Fri, 11 Feb 2000 11:24:01 +0100
Received: from wk by frodo.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12JDGC-0001EI-00; Fri, 11 Feb 2000 11:25:12 +0100
Date: Fri, 11 Feb 2000 11:25:12 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Return to MDC packet discussion
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Feb 10, 2000 at 05:41:15PM -0800
X-URL: http://www.openit.de
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 10 Feb 2000, [e-mail] wrote:

> We would specify that the reciever MUST NOT attempt to process any MDC
> message with an unknown MDC algorithm (or unknown version, although
> that is already implied).  It must treat the message as an error and
> not process it further, not display it to the user.

Okay.

> 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)

>    Unlike the Symmetrically Encrypted Data Packet, no special CFB
>    resynchronization is done after encrypting this prefix data.

Good.

This proposal is fine with me.  To implement this we have to add
feature flags to the public keys or choose an implicit way to decide
when a tag-15 packet should be used or is expected.  Using cipher
algorithms with a blocklength other the 64 bit should still work 
as an implicit criteria.


   Werner




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA20389 for ietf-openpgp-bks; Thu, 10 Feb 2000 17:41:22 -0800 (PST)
Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20385 for <[e-mail]>; Thu, 10 Feb 2000 17:41:19 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id RAA03277 for [e-mail]; Thu, 10 Feb 2000 17:41:15 -0800
Date: Thu, 10 Feb 2000 17:41:15 -0800
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Return to MDC packet discussion
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Greetings to Open-PGPers.  I would like to take up the topic we discussed
in May of 1999 without coming to a resolution, the MDC packet.  The
proposal I advanced at that time is appended below.  In this message
I discuss some of the motivation for that proposal, and suggest a way
of doing the change which many people wanted, to allow variation in the
MDC algorithm.


Several comments and changes were suggested, but as I have expressed
in the past, my concern is that they will weaken the security we want
to provide with the MDC packet.  Due to the nature of CFB encryption,
an attacker can do any XOR that he wants into any one block of
encrypted data, at the cost of totally corrupting the following block.
This means that suggestions to protect against modifications by
putting fields into the encrypted data will not work.

In particular, it is dangerous to have a field which allows specifying
which algorithm to use for the MDC.  The danger is that an attacker
can change the value of this field to some other algorithm.  Of course
the attacker cannot actually compute a valid MDC packet for that new
algorithm.  That is not the attack.  Rather he can change the
algorithm field to be an unknown/unsupported algorithm, one not yet
assigned.  The receiver then has no way of knowing whether this is the
result of such an attack, or whether it is receiving a message from a
newer OpenPGP version which uses a newer hash algorithm.

It was suggested that this attack could be prevented by putting other
data into the encrypted data, like a checksum for the MDC algorithm.
I think the idea was to include the prefix block of random data in the
checksum, along with the MDC alg value, all of which would be
encrypted.  However some checksum algorithms are transparent to XOR,
for example bytewise sum is transparent to XOR of the high bit
(meaning, checksum correctness is preserved if an input byte and the
checksum byte both have their high bit toggled).  Even with a 16 bit
arithmetic checksum as used in PGP secret keys, the attacker has a 50%
chance of successfully toggling the high bit.  I am unconvinced that
we can come up with a guaranteed safe checksum algorithm.

It was also suggested to put the packet version byte (1, for this
version) into the encrypted data to help prevent rollback attacks, but
for the reasons just mentioned the attacker can change this value in
the encrypted packet, so it does not work.

On further thought though I can see a way that we could safely allow
an MDC algorithm specification bit.

We would specify that the reciever MUST NOT attempt to process any MDC
message with an unknown MDC algorithm (or unknown version, although
that is already implied).  It must treat the message as an error and
not process it further, not display it to the user.

This would prevent the attacker from getting a modified message seen
by the receiver.  If all receivers follow this rule, then an attacker
knows that meddling with the version or MDC alg bytes will only cause
the message not to be seen, possibly with an error message that would
alert the user to the attack.  So this is no better for the attacker
than simply deleting the message, which he can presumably do if he is
able to alter bits.

I would be willing to accept an MDC algorithm specifier if we added
this rule.  My main worry is that an implementation might choose to
disregard this rule on the theory that it should show all possible
data to the user and let him decide how much to trust it.  I suppose
we can't protect people from themselves.

If we do this, though, I don't see any advantage to putting the MDC
algorithm (or packet version) into the encrypted data, for the reasons
discussed above.  I would propose to add the algorithm specifier in
the unencrypted packet header, just after the packet version described
below.

Comments?

Hal Finney
PGP Security, Inc.


=====


5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)

   The Symmetrically Encrypted Integrity Protected Data packet contains
   data encrypted with a symmetric-key algorithm and protected against
   modification by the SHA-1 hash algorithm. When it has been decrypted,
   it will typically contain other packets (often literal data packets
   or compressed data packets).  The last such decrypted packet must be
   a Modification Detection Code packet.

   The body of this packet consists of:

     - A one-octet version number.  The only currently defined value is 1.

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in Cipher Feedback mode with shift amount equal to the
       block size of the cipher (CFB-n where n is the block size).

   The symmetric cipher used MUST be specified in a Public-Key or
   Symmetric-Key Encrypted Session Key packet that precedes the
   Symmetrically Encrypted Data Packet.  In either case, the cipher
   algorithm octet is prefixed to the session key before it is
   encrypted.

   The data is encrypted in CFB mode, with a CFB shift size equal to
   the cipher's block size.  The Initial Vector (IV) is specified as
   all zeros.  Instead of using an IV, OpenPGP prefixes an octet string
   to the data before it is encrypted.  The length of the octet string
   equals the block size of the cipher in octets, plus two.  The first
   octets in the group, of length equal to the block size of the cipher,
   are random; the last two octets are each copies of their 2nd preceding
   octet.  For example, with a cipher whose block size is 128 bits or 16
   octets, the prefix data will contain 16 random octets, then two more
   octets, which are copies of the 15th and 16th octets, respectivelly.
   Unlike the Symmetrically Encrypted Data Packet, no special CFB
   resynchronization is done after encrypting this prefix data.

   The repetition of 16 bits in the random data prefixed to the message
   allows the receiver to immediately check whether the session key
   is incorrect.

   The plaintext of the data to be encrypted is passed through the SHA-1
   hash function, and the result of the hash is appended to the plaintext
   in a Modification Detection Code packet.  Specifically, the input to
   the hash function does not include the prefix data described above;
   it includes all of the plaintext, and then also includes two octets
   of values 0xD0, 0x14.  These represent the encoding of a Modification
   Detection Code packet tag and length field of 20 octets.

   The resulting hash value is stored in a Modification Detection Code
   packet which MUST use the two octet encoding just given to represent
   its tag and length field.  The body of the MDC packet is the 20 octet
   output of the SHA-1 hash.

   The Modification Detection Code packet is appended to the plaintext and
   encrypted along with the plaintext using the same CFB context.

   During decryption, the plaintext data should be hashed with SHA-1,
   not including the prefix data but including the packet tag and length
   field of the Modification Detection Code packet.  The body of the
   MDC packet, upon decryption, should be compared with the result of
   the SHA-1 hash.  Any difference in hash values is an indication that
   the message has been modified and SHOULD be reported to the user.
   Likewise, the absence of an MDC packet, or an MDC packet in any
   position other than the end of the plaintext, also represent message
   modifications and SHOULD also be reported.

   Note: future designs of new versions of this packet should consider
   rollback attacks since it will be possible for an attacker to change
   the version back to 1.


5.Y Modification Detection Code Packet (Tag 16)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data which is used to detect message modification.  It is
   only used in the context of a Symmetrically Encrypted Integrity
   Protected Data packet.  The Modification Detection Code packet MUST
   be the last packet in the plaintext data which is encrypted in the
   Symmetrically Encrypted Integrity Protected Data packet, and MUST
   appear in no other place.

   A Modification Detection Code packet MUST have a length of 20 octets.

   The body of this packet consists of:

     - A 20-octet SHA-1 hash of the preceding plaintext data of the
       Symmetrically Encrypted Integrity Protected Data packet, not
       including prefix data but including the tag and length byte of
       the Modification Detection Code packet.

   Note that the Modification Detection Code packet MUST always use a
   new-format encoding of the packet tag, and a one-octet encoding of
   the packet length.  (These requirements are already imposed by the
   rules for tag and length encoding.)


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29060 for ietf-openpgp-bks; Mon, 7 Feb 2000 08:20:02 -0800 (PST)
Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29055 for <[e-mail]>; Mon, 7 Feb 2000 08:20:01 -0800 (PST)
Received: from earthlink.net (pool0183.cvx11-bradley.dialup.earthlink.net [209.178.188.183]) by swan.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id IAA27513; Mon, 7 Feb 2000 08:22:36 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 07 Feb 2000 08:26:49 -0800
From: Marvin Williams <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: 2nd request: unsubscribe me 
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------0D5E2D67A93AB3958EEB455E"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--------------0D5E2D67A93AB3958EEB455E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe me

[e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.
>
>         Title           : Multiple Signatures using Security Multiparts
>         Author(s)       : D. Del Torto, R. Levien, T. Roessler
>         Filename        : draft-ietf-openpgp-multsig-00.txt
>         Pages           : 6
>         Date            : 04-Feb-00
>
> This document describes how the Security Multiparts defined in RFC
> 1847 [1] can be used to transport multiple digital signatures.
> This draft is being discussed on the 'ietf-openpgp' mailing list.  To
> join the list, send a message to <[e-mail]> with
> the single word 'subscribe' in the subject.  A web site containing an
> archive of the list can be found at
> <http://www.imc.org/ietf-openpgp>.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-multsig-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-openpgp-multsig-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [e-mail].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-openpgp-multsig-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[e-mail]>



--------------0D5E2D67A93AB3958EEB455E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
<B>unsubscribe me</B>

<P>[e-mail] wrote:
<BLOCKQUOTE TYPE=CITE>A New Internet-Draft is available from the on-line
Internet-Drafts directories.
<BR>This draft is a work item of the An Open Specification for Pretty Good
Privacy Working Group of the IETF.

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: Multiple Signatures using Security Multiparts
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: D. Del Torto, R. Levien, T. Roessler
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: draft-ietf-openpgp-multsig-00.txt
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 6
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 04-Feb-00

<P>This document describes how the Security Multiparts defined in RFC
<BR>1847 [1] can be used to transport multiple digital signatures.
<BR>This draft is being discussed on the 'ietf-openpgp' mailing list.&nbsp;
To
<BR>join the list, send a message to &lt;[e-mail]>
with
<BR>the single word 'subscribe' in the subject.&nbsp; A web site containing
an
<BR>archive of the list can be found at
<BR>&lt;<A HREF="http://www.imc.org/ietf-openpgp">http://www.imc.org/ietf-openpgp</A>>.

<P>A URL for this Internet-Draft is:
<BR><A HREF="http://www.ietf.org/internet-drafts/draft-ietf-openpgp-multsig-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-openpgp-multsig-00.txt</A>

<P>Internet-Drafts are also available by anonymous FTP. Login with the
username
<BR>"anonymous" and a password of your e-mail address. After logging in,
<BR>type "cd internet-drafts" and then
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "get draft-ietf-openpgp-multsig-00.txt".

<P>A list of Internet-Drafts directories can be found in
<BR><A HREF="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</A>
<BR>or <A HREF="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A>

<P>Internet-Drafts can also be obtained by e-mail.

<P>Send a message to:
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [e-mail].
<BR>In the body type:
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "FILE /internet-drafts/draft-ietf-openpgp-multsig-00.txt".

<P>NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document
in
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using
the "mpack" utility.&nbsp; To use this
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command
"ENCODING mime" before the "FILE"
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode
the response(s), you will need "munpack" or
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail reader.&nbsp;
Different MIME-compliant mail readers
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior,
especially when dealing with
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "multipart" MIME messages
(i.e. documents which have been split
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages),
so check your local documentation on
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these
messages.
<BR>&nbsp;

<P>Below is the data which will enable a MIME compliant mail reader
<BR>implementation to automatically retrieve the ASCII version of the
<BR>Internet-Draft.

<P>&nbsp; ------------------------------------------------------------------------
<BR>Content-Type: text/plain
<BR>Content-ID:&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]></BLOCKQUOTE>
&nbsp;</HTML>

--------------0D5E2D67A93AB3958EEB455E--



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA23106 for ietf-openpgp-bks; Mon, 7 Feb 2000 03:33:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA23102 for <[e-mail]>; Mon, 7 Feb 2000 03:33:08 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02018; Mon, 7 Feb 2000 06:35:51 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-multsig-00.txt
Date: Mon, 07 Feb 2000 06:35:51 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: Multiple Signatures using Security Multiparts
	Author(s)	: D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-multsig-00.txt
	Pages		: 6
	Date		: 04-Feb-00
	
This document describes how the Security Multiparts defined in RFC
1847 [1] can be used to transport multiple digital signatures.
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  A web site containing an
archive of the list can be found at
<http://www.imc.org/ietf-openpgp>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-multsig-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-multsig-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-multsig-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-multsig-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-multsig-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id AAA23911 for ietf-openpgp-bks; Sat, 5 Feb 2000 00:59:19 -0800 (PST)
Received: from atanda.com (abel.intermag.com [209.31.7.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA23904 for <[e-mail]>; Sat, 5 Feb 2000 00:59:17 -0800 (PST)
Received: from [192.168.248.7] (216.100.248.78) by atanda.com with ESMTP (Eudora Internet Mail Server 1.2.1); Sat, 5 Feb 2000 01:01:40 -0800
Mime-Version: 1.0
Message-Id: <p04301418b4c190a73aaa@[192.168.248.7]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Sender: 
Date: Sat, 5 Feb 2000 00:50:49 -0800
To: [e-mail]
From: Dave Del Torto <[e-mail]>
Subject: Re: Fw: Automated response from IMC Autoresponder <[e-mail]>
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 8:32 pm -0800 2000-02-04, caiboyx wrote:
>Date: Thu, 18 Mar 1999 17:25:9 +0800
>From: caiboyx <[e-mail]>
>To: "[e-mail]" <[e-mail]>
>Subject: Fw: Automated response from IMC Autoresponder <[e-mail]>
>
>     [material removed]


OK, Paul... time to change it again... ;)

Seriously, why make it so easy for spammers to zero in on the new address?
I thought you were kidding when you wished out loud that they didn't read.
We could at least make the reply message "spell" the new address out, so
the one-in-a-million spam-weasel who's actually literate also has to 
shatter the probability curves and know how to type! ;)

IOW, make it something like:

**************NOTICE**************

This Internet Engineering Task Force technical mailing list has changed
addresses due to large amounts of spam being received at the previous
list-address.

As of 2000-02-05, if you want to send email to the list, send it To:

  IETF-OpenPGP-WG @ IMC.ORG                    (just remove the spaces!)

If you need help, email:  PHOFFMAN @ IMC.ORG  (again, remove the spaces).

**************NOTICE**************



    dave

__________________________________________________________________________
"I don't even have an e-mail address. I have reached an age where my main
  purpose is not to receive messages." --Umberto Eco


Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11148 for ietf-openpgp-bks; Fri, 4 Feb 2000 20:02:23 -0800 (PST)
Received: from pub.jlonline.com ([202.102.24.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11144 for <[e-mail]>; Fri, 4 Feb 2000 20:02:22 -0800 (PST)
Received: from yy ([202.102.66.182]) by pub.jlonline.com (Netscape Messaging Server 4.05) with SMTP id FPFVBP00.XDG for <[e-mail]>; Sat, 5 Feb 2000 12:04:37 +0800 
Date: Thu, 18 Mar 1999 17:25:22 +0800
From: caiboyx <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Fw: Automated response from IMC Autoresponder <[e-mail]>
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA11145
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

ÄúºÃ£¡

*******ÏÂÃæÊÇת·¢µÄÓʼþ*****
This mailing list has moved. To send mail to the list, send to:
     [e-mail]
(note the lack of the second dash in the name). This list move
was caused by the large amount of spam being received by the old
mailing list.

If you have any questions, please send them to [e-mail].
*****ת·¢ÄÚÈݽáÊø*****



                    ÖÂ
Àñ£¡

            caiboyx
            [e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11140 for ietf-openpgp-bks; Fri, 4 Feb 2000 20:02:20 -0800 (PST)
Received: from pub.jlonline.com ([202.102.24.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11120 for <[e-mail]>; Fri, 4 Feb 2000 20:02:10 -0800 (PST)
Received: from yy ([202.102.66.182]) by pub.jlonline.com (Netscape Messaging Server 4.05) with SMTP id FPFVBC00.RBU for <[e-mail]>; Sat, 5 Feb 2000 12:04:24 +0800 
Date: Thu, 18 Mar 1999 17:25:9 +0800
From: caiboyx <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Fw: Automated response from IMC Autoresponder <[e-mail]>
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA11134
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

ÄúºÃ£¡

*******ÏÂÃæÊÇת·¢µÄÓʼþ*****
This mailing list has moved. To send mail to the list, send to:
     [e-mail]
(note the lack of the second dash in the name). This list move
was caused by the large amount of spam being received by the old
mailing list.

If you have any questions, please send them to [e-mail].
*****ת·¢ÄÚÈݽáÊø*****



                    ÖÂ
Àñ£¡

            caiboyx
            [e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id PAA08159 for ietf-openpgp-bks; Thu, 3 Feb 2000 15:28:29 -0800 (PST)
Received: from enterprise.powerup.com.au (IDENT:[e-mail] [203.32.8.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA08153 for <[e-mail]>; Thu, 3 Feb 2000 15:28:26 -0800 (PST)
Message-Id: <[e-mail]>
Received: (qmail 6849 invoked from network); 3 Feb 2000 23:30:28 -0000
Received: from unknown (HELO lindsay) (203.147.171.117) by enterprise.powerup.com.au with SMTP; 3 Feb 2000 23:30:28 -0000
Date: 2 Feb 2000 8:23:28 GMT
From: Lindsay Mathieson <[e-mail]>
Mime-Version: 1.0
Subject: Re: [Pgp-mime] s/MIME: content-type: multipart/mixed
To: [e-mail]
X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.8 Preview 4
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>> There is a technology from New Zealand called RPK 
>> http://www.rpk.co.nz or http://crypto.swdev.co.nz that also is
>available > in high strength and is currently being implemented as a
>seamless add-in > for MAPI based e-mail packages (that covers >80% of
>the market).  

I looked at it - it appears to be compatible with neither S/MIME or PGP/MIME,
so it would appear to be a non-starter.

--
Lindsay Mathieson
Black Paw Communications
 Using MailCat for Win32 Beta Vs 2.8 Preview 4, on February 4, 2000, in Win95
4.0
 http://www.blackpaw.com/



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA10778 for ietf-openpgp-bks; Wed, 2 Feb 2000 05:20:22 -0800 (PST)
Received: from pharos.hsp.de (pharos.hsp.de [194.77.127.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10773 for <[e-mail]>; Wed, 2 Feb 2000 05:20:19 -0800 (PST)
Received: (from uucp@localhost) by pharos.hsp.de with UUCP id OAA18898 for [e-mail]; Wed, 2 Feb 2000 14:20:36 +0100
Received: from (frodo.gnupg.de) [194.231.77.148] (mail) by beren.gnupg.de with esmtp (Exim 1.92 #1 (Debian)) id 12Fzcc-000881-00; Wed, 2 Feb 2000 14:15:02 +0100
Received: from wk by frodo.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12Fzbq-0000se-00; Wed, 2 Feb 2000 14:14:14 +0100
Date: Wed, 2 Feb 2000 14:14:14 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: rfc2440bis checklist
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
X-URL: http://www.openit.de/wks
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi, 

I have compiled the list of SHOULD and MUST.  What do we else need to
check interoperability?  


This is a list of all MUST and SHOULD requirements of the
draft-ietf-openpgp-rfc2440bis-00.txt.  Note, that the section
numbering in 5.2.3 is shifted against rfc2440.

Version: wk 2000-02-02

Section  MS  Summary of requirement
-------  --  ----------------------

2.3	 S   OpenPGP implementations SHOULD compress the message after
	     applying the signature but before encryption.

2.4	 S   Implementations SHOULD provide Radix-64 conversions.

2.4	 S   An application that implements OpenPGP for messaging
	     SHOULD implement OpenPGP-MIME (rfc2015).

3.3	 S   Implementations SHOULD NOT assume that Key IDs are unique.

3.6.2	 S   Implementations SHOULD use salted or iterated-and-salted S2K.

3.6.2.1  S   Secret Key encryption with an implicit use of MD5 and IDEA
	     SHOULD NOT be generated.

4.2.1	 S   An implementation SHOULD NOT use indeterminate length packets
	     of old format except where the end of the data will be clear
	     from the context.

4.2.2.4  M   The last length header in the packet MUST NOT be a
	     partial Body Length header.

4.2.3	 M   1st partial length MUST be at least 512 bytes long.

4.2.3	 M   Partial Body Lengths MUST NOT be used for packet types
	     other than compressed (8), encrypted (9), literal (11).

5.1	 M   For multiple Public Key Encrypted Session Key packets,
	     implementations MUST make new PKCS-1 padding for each key.

5.2	 M   Implementations MUST accept V3 signatures.

5.2	 S   Implementations SHOULD generate V4 signatures.

5.2.2	 M   The one-octet length of following hashed material
	     MUST be 5 in V3 signature packets.

5.2.2	 M   DSA signatures MUST use hashes with a size of 160 bits.

5.2.3.1  S   An implementation SHOULD ignore any signature subpacket of a type
	     that it does not recognize, but if is marked crtitical the
	     implemenation SHOULD consider the signature in error.

5.2.3.1  S   Implementations SHOULD implement "preferences".

5.2.3.3  S   An implementation SHOULD allow the user to rewrite the
	     self-signature, and important information in it.

5.2.3.4  M   The signature creation time sub-packet MUST be in the hashed
	     area of a V4 signature packet.

5.2.3.13 S   Trust signature: Implementations SHOULD emit values
	     of 60 for partial trust and 120 for complete trust.

5.2.3.15 S   Revocation key: If the "sensitive" flag is set, an implementation
	     SHOULD NOT export this signature to other users except in cases
	     where the data needs to be available.

5.2.3.16 M   In Notation Data subpacket all undefined flags in the flag
	     field MUST be zero.

5.2.3.17 M   In key server preferences, all undefined flags MUST be zero.

5.2.3.21 M   In the Key flags an implementaion MOST NOT assume a fixed size.

5.2.3.21 S   Key flags SHOULD be placed only on a direct-key signature (type
	     0x1f) or a subkey signature (type 0x18).

5.2.3.23 S   An implementation SHOULD implement the Reason For Revocation
	     subpacket, include it in all revocation signatures, and
	     interpret revocations appropriately.

5.2.3.23 S   A revocation of a self-signature on a user id SHOULD include
	     the 0x20 reason code.  [The draft calls it subpacket, but this
	     seems to be wrong]

5.2.4.1  S   An implementation SHOULD put the two mandatory subpackets,
	     creation time and issuer, as the first subpackets in the list.

5.2.4.1  S   An implementation SHOULD use the last subpacket in the signature
	     to resove conflicts.

5.3	 M   The S2K specifier in a Symmentric Key Encrypted Session Key
	     packet MUST be Salted or Iterated and Salted.

5.5.2	 M   v2 packets MUST NOT be generated.

5.5.2	 S   OpenPGP implementations SHOULD create keys with version 4 format.

5.5.2	 M   An implementation MUST NOT create a v3 packet with an algorithm
	     other than RSA.

5.5.2	 S   V3 keys SHOULD only be used for backward compatibility.

5.5.3	 S   Implementations SHOULD use a string-to-key specifier except for
	     backward compatibility.

5.8	 M   Marker packets (tag 10) MUST be ignored when received.

5.10	 S   Trust packets SHOULD NOT be emitted to output streams that are
	     transferred to other users.

5.10	 S   Trust pakets SHOULD be ignored on any input other than local
	     keyring files.

6.2	 M   The armor header lines MUST start at the beginning of a line.

6.2	 M   The armor header lines MUST NOT have text following them on the
	     same line.

6.2	 S   The MessageID SHOULD NOT appear unless it is in a multi-part
	     message.

6.2	 M   The Message Armor header 'MessageID' (if it appears) MUST be
	     computed from the encrypted signed message in a deterministic
	     fashion.

9.1	 M   MUST implement DSA for signatures.

9.1	 M   MUST implement ElGamal for encryption.

9.1	 S   Implementations SHOULD implement RSA keys.

9.2	 M   MUST implement 3-DES for symmetric encryption.

9.2	 S   Implementations SHOULD implement IDEA.

9.2	 S   Implementations SHOULD implement CAST5.

9.3	 M   Implementations MUST implement uncompressed data.

9.3	 S   Implementations SHOULD implement ZIP.

9.4	 M   Implementations MUST implement SHA-1.

9.4	 S   Implementations SHOULD implement MD5.

11.1	 M   In keys with main keys and sub keys, the primary key MUST be
	     capable of signing.
	     Remark:  This make it possible to have a single encryption only
		      key

12.1	 MS  If an algorithm used in encryption is not in the user's
	     preference list, the implementation SHOULD decrypt anyway
	     but MUST warn the user of the protocol violation.

12.1	 M   An implementation MUST NOT use a symmetric algorithm that is not
	     in the recipient's preference list.

12.1	 S   An implementation MAY, but SHOULD NOT use IDEA to solve
	     an algorithm conflict with a V3 key.

12.2.1	 M   An implementation MUST NOT use a compression algorithm that is
	     not in the compression preference vector.

12.2.1	 M   An implementation MUST implement the compression preference to
	     the degree of recognizing when to send an uncompressed message.

12.3	 M   Implementations MUST NOT use plaintext in Symmetrically
	     Encrypted Data Packets; they must use Literal Data Packets.

12.4	 M   Implementations supporting RSA in V4 keys MUST implement all
	     MUST features from V4 key section.

12.4	 S   An implementation SHOULD NOT create keys of types
	     RSA-signature-only and RSA-encrypt-only.

12.4	 S   An implementation SHOULD NOT implement RSA keys of size
	     less than 768 bits.

12.5	 M   If an implementation allows ELGamal signatures, then it
	     MUST use the algorithm id 20 for an ElGamal public key that
	     can sign.

12.5	 S   Implementations SHOULD choose an ElGamal prime p, so that
	     (p-1)/2 are also primes.

12.5	 S   An implementation SHOULD NOT implement Elgamal keys of
	     size less than 768 bits.

12.6	 S   An implementation SHOULD NOT implement DSA keys of
	     size less than 768 bits.

12.6	 M   DSA keys MUST be an even multiple of 64 bits long.



[based on initial work by Tony Mione <[e-mail]>
 posted to the OpenPGP list Tue, 20 Jul 1999 17:09:08 -0400]


-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013