Re: critical bit (5.2.3.1)

[Jon Callas <[e-mail]>]

At 10:38 AM 9/30/98 +0200, Werner Koch wrote:
   
   Can we restrict the SHOULD to hashed subpackets?  Otherwise it is
   easy to invalidate a signature by setting the critical bit in a
   unhashed subpacket.
   
Remember what SHOULD means:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

If you, as a developer, believe that there is greater danger in the
potential denial-of-service attack from critical unhashed subpackets than
there is value from them, you are free to ignore it.

	Jon



-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02069 for ietf-open-pgp-bks; Wed, 30 Sep 1998 13:55:26 -0700 (PDT)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02065 for <[e-mail]>; Wed, 30 Sep 1998 13:55:25 -0700 (PDT)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA20918; Wed, 30 Sep 1998 14:01:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 30 Sep 1998 13:59:14 -0700
To: Werner Koch <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: critical bit (5.2.3.1)
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:38 AM 9/30/98 +0200, Werner Koch wrote:
   
   Can we restrict the SHOULD to hashed subpackets?  Otherwise it is
   easy to invalidate a signature by setting the critical bit in a
   unhashed subpacket.
   
Remember what SHOULD means:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

If you, as a developer, believe that there is greater danger in the
potential denial-of-service attack from critical unhashed subpackets than
there is value from them, you are free to ignore it.

	Jon



-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02060 for ietf-open-pgp-bks; Wed, 30 Sep 1998 13:54:54 -0700 (PDT)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02056 for <[e-mail]>; Wed, 30 Sep 1998 13:54:53 -0700 (PDT)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA20915; Wed, 30 Sep 1998 14:01:07 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 30 Sep 1998 13:48:57 -0700
To: Ian BROWN <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: error in draft 07, section 5.1 ?
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 29 Sep 1998 14:42:52 PDT." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:13 AM 9/30/98 +0200, Ian BROWN wrote:
   >Yes, you appear to be correct.  The algorithm identifier is not included
   >in the checksum.
   
   Did nobody notice the three messages that Ulf Moller and I sent about this 
   starting more than a month ago?
   
I noticed. The -07 draft had modifications in it from your comments.

	Jon



-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01861 for ietf-open-pgp-bks; Wed, 30 Sep 1998 13:23:51 -0700 (PDT)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA01857; Wed, 30 Sep 1998 13:23:50 -0700 (PDT)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Wed, 30 Sep 1998 14:30:02 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 30 Sep 1998 14:29:51 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id NAB01858
Sender: [e-mail]
Precedence: bulk

Regarding the need for business access to encrypted communications --
I agree that the need is not strong, and I would hate to have to make the business case for a product that had that as its central justification, but there are valid examples outside of the military/intelligence community.

You might want to look at the key Recovery Alliance's web site www.kra.org for the Business Scenarios report, which addresses some of these needs for business key recovery, even for transitive communications.

Examples include review of outgoing communications by stock brokers to ensure that they are not engaging in insider trading (I believe this is imposed by law), companies who may have a positive duty to investigate a claimed case of sexual harassment, internal investigations of possible fraud or theft of trade secret information, etc.

Completely independent of these scenarios, there may be an additional requirement for server-based encryption of outgoing e-mail to support disconnected operation.

If a user composes an email message on his laptop while on an airplane, he may not have access to the recipient's certificates, and in particular, almost surely does not have access to the current CRLs.  Since the message can't be transmitted until the user reconnects, it may be acceptable and perhaps even desirable to have the server perform the encryption in the recipient's public key, after checking the CRLs, without necessarily making the user wait for all this while he is on a pay phone in the airport.  This doesn't mean that the information goes from the client to the server in the clear -- a symmetric key could easily be used.  

On the other hand, the checking of the certificates could be deferred, and the outgoing mail returned if the certificate has expired or been revoked. This would not require the server to be trusted.  

Obviously most users would probably prefer this option, but in most companies the users don't buy the software does, the IS department does, and their needs may therefore dominate.

Caveat emptor.

Bob

>>> William Ottaway <[e-mail]> 09/29 1:56 AM >>>
At 18:48 28/09/98 +0100, Adam Back wrote:
>
>Bill Ottaway writes:
>> However, organisations want to control the release of messages from their
>> employees.  They want to make sure outgoing messagers do not contain any
>> sensitive information or viruses. If the sender encrypts his mail
>> using the recipients key the organisation can not perform any of
>> these checks.
>
>Snooping outgoing email for sensitive information isn't a general
>commercial requirement.
>
>It is predominantly a government / signals intelligence special
>interest goal.
>
>UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
>to allow snooping on sent and received email.
>
>CASM is partly based on server encryption.  Bill works for DERA
>(dera.gov.uk), so I am wondering if he is thinking of CASM in his
>comments, in that some of his arguments are couched in terms of a
>desire for mail snooping, while others were discussing server
>decryption purely in terms of ease of deployment, and adding blanket
>super-encryption, security and forward-secrecy for email that would
>otherwise not be encrypted.
>

No I wasn't thinking of CASM. I was just making a point that certain
organisations will want to be able to check their employees email for one
reason or another, this is not a military/government only issue.

Once companies start signing outgoing mail, which they will do, they are
taking some responsibility for the contents of that message. If that
message contained a virus then they could be sued for damage caused by that
virus. Signing is also a powerful mechanism which can be used in financial
transactions. Joe Blogs might not have the authority to perform financial
transactions, but a rubber seal from his organisation does carry the this
authority. This sort of transaction may need to be encrypted so that other
commercial organisations do not get wind of what you are up to. 

Yes the military and government have sensitive information which they do
not want to be mailed out of their organisations, but so do commercial
organisations (e.g. trade secrets, research, etc). This may not be a
requirement of all commercial companies but it still needs to be taken into
account when considering signing and encrypting messages. 

I would expect all large organisations, military, government or commercial
to require the ability to check employees email and to do
encryption/signing by the organisation.




>(CASM includes a form of GACK involving recomputing seed material, for
>details see:
>
>	http://www.opengroup.org/public/tech/security/pki/cki/ 
>
>)
>
>(As an aside, IMO, CASM is not a very elegant protocol: it has many
>online messages, uses public key crypto where symmetric could acheive
>the same effect with equal security, and has a centralised risk of the
>seed material of the root node of the hierarchy being compromised.)
>
>Shared keys or server encryption copes with multiple recipients
>needing to be able to decrypt messages (the `sales team' scenario).
>
>Server encryption is useful to augment personal key based security,
>and/or to speed deployment of "some" encryption even if not at first
>cut personal key based.
>
>I agree with Bill's comments about reduced PKI overhead of server
>based crypto, and his ease of deployment comments.
>
>Adam

Bill.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29623 for ietf-open-pgp-bks; Wed, 30 Sep 1998 09:35:54 -0700 (PDT)
Received: from consensus.com (mail.consensus.com [157.22.240.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29619 for <[e-mail]>; Wed, 30 Sep 1998 09:35:53 -0700 (PDT)
Received: from haruspex (209.121.99.2) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 30 Sep 1998 09:47:54 -0700
From: "Tim Dierks" <[e-mail]>
To: "Hal Finney" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: critical bit (5.2.3.1)
Date: Wed, 30 Sep 1998 09:42:50 -0700
Message-ID: <009b01bdec91$5c81b7a0$2906010a@haruspex>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

Hal Finney writes:
> Werner Koch, <[e-mail]>, writes:
> > >From section 5.2.3.1:
> >
> > > Bit 7 of the subpacket type is the "critical" bit.  If set, it
> > > denotes that the subpacket is one that is critical for the evaluator
> > > of the signature to recognize.  If a subpacket is encountered that
> > > is marked critical but is unknown to the evaluating software, the
> > > evaluator SHOULD consider the signature to be in error.
> >
> > Can we restrict the SHOULD to hashed subpackets?  Otherwise it is
> > easy to invalidate a signature by setting the critical bit in a
> > unhashed subpacket.
> If I create a signature and set the critical bit on an unhashed packet,
> it means that I want you to understand that packet before you accept
> the signature.  So in this case it is my desire that the signature should
> be invalidated if you don't understand the packet.
>
> If an attacker tries to make a signature invalid by adding an unhashed
> packet with the critical bit set, he could have just as easily modified
> some part of the hashed region, or the signature itself.

I agree with this; however, the converse is a problem. If you make an
unhashed packet critical, an attacker can turn the critical bit off without
invalidating the security; this means that critical bits cannot be relied
upon, and as such should not be part of the signature validation procedure.
I would suggest that critical bits only be supported in hashed subpackets.

 - Tim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29611 for ietf-open-pgp-bks; Wed, 30 Sep 1998 09:34:42 -0700 (PDT)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29607 for <[e-mail]>; Wed, 30 Sep 1998 09:34:41 -0700 (PDT)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.1/8.9.1) with ESMTP id JAA14820; Wed, 30 Sep 1998 09:40:56 -0700 (PDT)
Received: (from hal@localhost) by hal.sb.rain.org (8.7.4/8.7.3) id JAA11403; Wed, 30 Sep 1998 09:39:38 -0700
Date: Wed, 30 Sep 1998 09:39:38 -0700
From: Hal Finney <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: critical bit (5.2.3.1)
Sender: [e-mail]
Precedence: bulk

Even though that particular attack may not be a problem, you are right
that it seems illogical to set the critical bit on an unhashed packet.

Making a packet unhashed is saying that there are no security implications
if the packet is altered or removed.  But setting the critical bit means
that there are security implications if the packet is not understood.
Doing both at once means that you don't care if the packet is altered or
removed, but that it must be understood, which doesn't make much sense.

Hal


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29291 for ietf-open-pgp-bks; Wed, 30 Sep 1998 08:58:36 -0700 (PDT)
Received: from koeln.shuttle.de ([e-mail] [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29287 for <[e-mail]>; Wed, 30 Sep 1998 08:58:34 -0700 (PDT)
Received: by koeln.shuttle.de (8.9.0/8.9.0) id SAA10729 for [e-mail]; Wed, 30 Sep 1998 18:05:35 +0200 (MET DST)
Received: (qmail 2507 invoked from network); 30 Sep 1998 15:53:29 -0000
Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 30 Sep 1998 15:53:29 -0000
Received: (qmail 14074 invoked by uid 501); 30 Sep 1998 15:52:27 -0000
Message-ID: <[e-mail]>
Date: Wed, 30 Sep 1998 17:52:27 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: critical bit (5.2.3.1)
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Mutt 0.93i
In-Reply-To: <[e-mail]>; from Hal Finney on Wed, Sep 30, 1998 at 07:48:06AM -0700
X-URL: http://www.d.shuttle.de/isil
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hal Finney <[e-mail]> writes:

> If an attacker tries to make a signature invalid by adding an unhashed
> packet with the critical bit set, he could have just as easily modified
> some part of the hashed region, or the signature itself.

I thought about it while working on the import stuff; but you are
right it doesn't matter whether the critical bit is in the hashed or
unhashed region.  

Thanks,

  Werner



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28809 for ietf-open-pgp-bks; Wed, 30 Sep 1998 07:42:27 -0700 (PDT)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28805 for <[e-mail]>; Wed, 30 Sep 1998 07:42:26 -0700 (PDT)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.1/8.9.1) with ESMTP id HAA05510; Wed, 30 Sep 1998 07:49:24 -0700 (PDT)
Received: (from hal@localhost) by hal.sb.rain.org (8.7.4/8.7.3) id HAA11283; Wed, 30 Sep 1998 07:48:06 -0700
Date: Wed, 30 Sep 1998 07:48:06 -0700
From: Hal Finney <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: critical bit (5.2.3.1)
Sender: [e-mail]
Precedence: bulk

Werner Koch, <[e-mail]>, writes:
> >From section 5.2.3.1:
>
> > Bit 7 of the subpacket type is the "critical" bit.  If set, it
> > denotes that the subpacket is one that is critical for the evaluator
> > of the signature to recognize.  If a subpacket is encountered that
> > is marked critical but is unknown to the evaluating software, the
> > evaluator SHOULD consider the signature to be in error.
>
> Can we restrict the SHOULD to hashed subpackets?  Otherwise it is
> easy to invalidate a signature by setting the critical bit in a
> unhashed subpacket.

I'm not sure what issue you are concerned with;

If I create a signature and set the critical bit on an unhashed packet,
it means that I want you to understand that packet before you accept
the signature.  So in this case it is my desire that the signature should
be invalidated if you don't understand the packet.

If an attacker tries to make a signature invalid by adding an unhashed
packet with the critical bit set, he could have just as easily modified
some part of the hashed region, or the signature itself.

Hal


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA21964 for ietf-open-pgp-bks; Wed, 30 Sep 1998 02:07:24 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA21959 for <[e-mail]>; Wed, 30 Sep 1998 02:07:02 -0700 (PDT)
Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP  id <[e-mail]>; Wed, 30 Sep 1998 10:13:34 +0100
X-Mailer: exmh version 1.6.6 3/24/96
To: [e-mail]
Subject: Re: error in draft 07, section 5.1 ?
In-reply-to: Your message of "Tue, 29 Sep 1998 14:42:52 PDT." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 30 Sep 1998 10:13:33 +0200
Message-ID: <[e-mail]>
From: Ian BROWN <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>Yes, you appear to be correct.  The algorithm identifier is not included
>in the checksum.

Did nobody notice the three messages that Ulf Moller and I sent about this 
starting more than a month ago?

Ian.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA20750 for ietf-open-pgp-bks; Wed, 30 Sep 1998 01:43:52 -0700 (PDT)
Received: from koeln.shuttle.de ([e-mail] [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA20744 for <[e-mail]>; Wed, 30 Sep 1998 01:43:50 -0700 (PDT)
Received: by koeln.shuttle.de (8.9.0/8.9.0) id KAA04147 for [e-mail]; Wed, 30 Sep 1998 10:50:38 +0200 (MET DST)
Received: (qmail 2091 invoked from network); 30 Sep 1998 08:39:41 -0000
Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 30 Sep 1998 08:39:41 -0000
Received: (qmail 10489 invoked by uid 501); 30 Sep 1998 08:38:36 -0000
Message-ID: <[e-mail]>
Date: Wed, 30 Sep 1998 10:38:36 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: critical bit (5.2.3.1)
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
X-Mailer: Mutt 0.93i
X-URL: http://www.d.shuttle.de/isil
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

>From section 5.2.3.1:

> Bit 7 of the subpacket type is the "critical" bit.  If set, it
> denotes that the subpacket is one that is critical for the evaluator
> of the signature to recognize.  If a subpacket is encountered that
> is marked critical but is unknown to the evaluating software, the
> evaluator SHOULD consider the signature to be in error.

Can we restrict the SHOULD to hashed subpackets?  Otherwise it is
easy to invalidate a signature by setting the critical bit in a
unhashed subpacket.


  Werner 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA01978 for ietf-open-pgp-bks; Tue, 29 Sep 1998 14:37:39 -0700 (PDT)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA01974 for <[e-mail]>; Tue, 29 Sep 1998 14:37:38 -0700 (PDT)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.1/8.9.1) with ESMTP id OAA28505; Tue, 29 Sep 1998 14:44:11 -0700 (PDT)
Received: (from hal@localhost) by hal.sb.rain.org (8.7.4/8.7.3) id OAA09963; Tue, 29 Sep 1998 14:42:52 -0700
Date: Tue, 29 Sep 1998 14:42:52 -0700
From: Hal Finney <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: error in draft 07, section 5.1 ?
Sender: [e-mail]
Precedence: bulk

Werner Koch, <[e-mail]>, writes:
> >From section 5.1:
>
> > algorithm used to encrypt the following Symmetrically Encrypted Data
> > Packet.  Then a two-octet checksum is appended which is equal to the
> > sum of the preceding octets, including the algorithm identifier and
> > session key, modulo 65536.   algorithm used to encrypt the following
>
> I don't see that the algorithm identifier is included in the checksum.
> Both, gnupg and opgpg 0.99x, don't include the algorithm in the
> checksum and interoperation with pgp 5.x is okay.

Yes, you appear to be correct.  The algorithm identifier is not included
in the checksum.

Hal Finney


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00809 for ietf-open-pgp-bks; Tue, 29 Sep 1998 12:03:00 -0700 (PDT)
Received: from koeln.shuttle.de ([e-mail] [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00805 for <[e-mail]>; Tue, 29 Sep 1998 12:02:58 -0700 (PDT)
Received: by koeln.shuttle.de (8.9.0/8.9.0) id VAA21824 for [e-mail]; Tue, 29 Sep 1998 21:09:52 +0200 (MET DST)
Received: (qmail 1207 invoked from network); 29 Sep 1998 19:09:07 -0000
Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 29 Sep 1998 19:09:07 -0000
Received: (qmail 9598 invoked by uid 501); 29 Sep 1998 19:07:55 -0000
Message-ID: <[e-mail]>
Date: Tue, 29 Sep 1998 21:07:55 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: error in draft 07, section 5.1 ?
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
X-Mailer: Mutt 0.93i
X-URL: http://www.d.shuttle.de/isil
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

While checking GNUPG's OpenPGP compliance I detected this:

>From section 5.1:

> algorithm used to encrypt the following Symmetrically Encrypted Data
> Packet.  Then a two-octet checksum is appended which is equal to the
> sum of the preceding octets, including the algorithm identifier and
> session key, modulo 65536.   algorithm used to encrypt the following

I don't see that the algorithm identifier is included in the checksum.
Both, gnupg and opgpg 0.99x, don't include the algorithm in the
checksum and interoperation with pgp 5.x is okay.

Maybe I'm blind, but ...


BTW, as far as I can see, gnupg 0.4.1 (will be released soon) is in
compliance with the draft.


  Werner






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA27104 for ietf-open-pgp-bks; Tue, 29 Sep 1998 00:50:20 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA27095 for <[e-mail]>; Tue, 29 Sep 1998 00:50:18 -0700 (PDT)
Received: (qmail 9082 invoked from network); 29 Sep 1998 07:57:02 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 29 Sep 1998 07:57:02 -0000
Received: (qmail 3117 invoked from network); 29 Sep 1998 07:57:03 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 29 Sep 1998 07:57:03 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 29 Sep 1998 08:56:36 +0100
To: Adam Back <[e-mail]>
From: William Ottaway <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822  headers in S/MIME or PGP/MIME messages)
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 18:48 28/09/98 +0100, Adam Back wrote:
>
>Bill Ottaway writes:
>> However, organisations want to control the release of messages from their
>> employees.  They want to make sure outgoing messagers do not contain any
>> sensitive information or viruses. If the sender encrypts his mail
>> using the recipients key the organisation can not perform any of
>> these checks.
>
>Snooping outgoing email for sensitive information isn't a general
>commercial requirement.
>
>It is predominantly a government / signals intelligence special
>interest goal.
>
>UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
>to allow snooping on sent and received email.
>
>CASM is partly based on server encryption.  Bill works for DERA
>(dera.gov.uk), so I am wondering if he is thinking of CASM in his
>comments, in that some of his arguments are couched in terms of a
>desire for mail snooping, while others were discussing server
>decryption purely in terms of ease of deployment, and adding blanket
>super-encryption, security and forward-secrecy for email that would
>otherwise not be encrypted.
>

No I wasn't thinking of CASM. I was just making a point that certain
organisations will want to be able to check their employees email for one
reason or another, this is not a military/government only issue.

Once companies start signing outgoing mail, which they will do, they are
taking some responsibility for the contents of that message. If that
message contained a virus then they could be sued for damage caused by that
virus. Signing is also a powerful mechanism which can be used in financial
transactions. Joe Blogs might not have the authority to perform financial
transactions, but a rubber seal from his organisation does carry the this
authority. This sort of transaction may need to be encrypted so that other
commercial organisations do not get wind of what you are up to. 

Yes the military and government have sensitive information which they do
not want to be mailed out of their organisations, but so do commercial
organisations (e.g. trade secrets, research, etc). This may not be a
requirement of all commercial companies but it still needs to be taken into
account when considering signing and encrypting messages. 

I would expect all large organisations, military, government or commercial
to require the ability to check employees email and to do
encryption/signing by the organisation.




>(CASM includes a form of GACK involving recomputing seed material, for
>details see:
>
>	http://www.opengroup.org/public/tech/security/pki/cki/
>
>)
>
>(As an aside, IMO, CASM is not a very elegant protocol: it has many
>online messages, uses public key crypto where symmetric could acheive
>the same effect with equal security, and has a centralised risk of the
>seed material of the root node of the hierarchy being compromised.)
>
>Shared keys or server encryption copes with multiple recipients
>needing to be able to decrypt messages (the `sales team' scenario).
>
>Server encryption is useful to augment personal key based security,
>and/or to speed deployment of "some" encryption even if not at first
>cut personal key based.
>
>I agree with Bill's comments about reduced PKI overhead of server
>based crypto, and his ease of deployment comments.
>
>Adam

Bill.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05212 for ietf-open-pgp-bks; Mon, 28 Sep 1998 10:42:20 -0700 (PDT)
Received: from exeter.ac.uk (hermes.ex.ac.uk [144.173.6.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA05199; Mon, 28 Sep 1998 10:41:53 -0700 (PDT)
Received: from dialup18 [144.173.6.218] by hermes via ESMTP (SAA21993); Mon, 28 Sep 1998 18:48:43 +0100 (BST)
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id SAA18304; Mon, 28 Sep 1998 18:48:06 +0100
Date: Mon, 28 Sep 1998 18:48:06 +0100
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from William Ottaway on Mon, 28 Sep 1998 17:00:48 +0100)
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [e-mail]
Precedence: bulk

Bill Ottaway writes:
> However, organisations want to control the release of messages from their
> employees.  They want to make sure outgoing messagers do not contain any
> sensitive information or viruses. If the sender encrypts his mail
> using the recipients key the organisation can not perform any of
> these checks.

Snooping outgoing email for sensitive information isn't a general
commercial requirement.

It is predominantly a government / signals intelligence special
interest goal.

UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
to allow snooping on sent and received email.

CASM is partly based on server encryption.  Bill works for DERA
(dera.gov.uk), so I am wondering if he is thinking of CASM in his
comments, in that some of his arguments are couched in terms of a
desire for mail snooping, while others were discussing server
decryption purely in terms of ease of deployment, and adding blanket
super-encryption, security and forward-secrecy for email that would
otherwise not be encrypted.

(CASM includes a form of GACK involving recomputing seed material, for
details see:

	http://www.opengroup.org/public/tech/security/pki/cki/

)

(As an aside, IMO, CASM is not a very elegant protocol: it has many
online messages, uses public key crypto where symmetric could acheive
the same effect with equal security, and has a centralised risk of the
seed material of the root node of the hierarchy being compromised.)

Shared keys or server encryption copes with multiple recipients
needing to be able to decrypt messages (the `sales team' scenario).

Server encryption is useful to augment personal key based security,
and/or to speed deployment of "some" encryption even if not at first
cut personal key based.

I agree with Bill's comments about reduced PKI overhead of server
based crypto, and his ease of deployment comments.

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA04112 for ietf-open-pgp-bks; Mon, 28 Sep 1998 08:54:33 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA04103 for <[e-mail]>; Mon, 28 Sep 1998 08:54:31 -0700 (PDT)
Received: (qmail 21324 invoked from network); 28 Sep 1998 16:01:16 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 28 Sep 1998 16:01:16 -0000
Received: (qmail 22588 invoked from network); 28 Sep 1998 16:01:16 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 28 Sep 1998 16:01:16 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 28 Sep 1998 17:00:48 +0100
To: "William H. Geiger III" <[e-mail]>, "Blake Ramsdell" <[e-mail]>
From: William Ottaway <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Cc: "Steve Hole" <[e-mail]>, "Ned Freed" <[e-mail]>, <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 16:00 25/09/98 -0500, William H. Geiger III wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In <[e-mail]>, on 09/25/98 
>   at 01:47 PM, "Blake Ramsdell" <[e-mail]> said:
>
>>> -----Original Message-----
>>> From: William H. Geiger III [mailto:[e-mail]]
>>> Sent: Friday, September 25, 1998 1:22 PM
>>> To: Steve Hole
>>> Cc: Ned Freed; [e-mail]; [e-mail]
>>> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
>>> 
>>> In <[e-mail]>, on 09/18/98 
>>>    at 10:55 AM, Steve Hole <[e-mail]> said:
>>> 
>>> >Also there has been discussion many times in the past of 
>>> having "proxy 
>>> >security handling" for IMAP servers where the IMAP server handles
>>> >decoding encrypted messages on behalf of the client and sending the
>>> >decoded content over an encrypted data connection to the 
>>> client.   Note
>>> >that this is not a  real situation now, but there are lots 
>>> of reasons for
>>> >people to want this  behaviour in the future and it continues to be
>>> >discussed.
>>> 
>>> IMHO this is *not* a good idea.
>>> 
>>> The purpose of using end-to-end encryption is to avoid the 
>>> use of unknown
>>> 3 party systems to relay encrypted data. Decrypting on the server then
>>> re-encrypting via different means devalues the original encryption and
>>> brings unnecessary exposure of the raw data. It would also 
>>> require that
>>> the decryption keys of the recipient be stored on the server adding an
>>> added level of insecurity.
>
>>The originator can encrypt for the server, which will then decrypt the
>>message and send it on to the recipient.  The server does not need to
>>have the recipient's private key -- in fact, the recipient may not have a
>>keypair at all (only the server).  The value of the original encryption
>>is to keep things protected at the message level over the public
>>Internet, and then place the plaintext on the local trusted network. 
>>This allows for organizations to implement message-level security without
>>having to put cryptography on the individual desktops.
>
>I don't like it. It goes against the concepts of end-to-end encryption. If
>I want to send an encrypted message to someone, I want *only* that
>recipient to be able to read that message, not someone down in MIS, not
>some mail clerk, or god knows who else that has access to the local
>network. This is the whole point of end-to-end encryption, I don't have to
>"trust" any network security, all I have to trust is my local security and
>my recipient's local security. While not putting encryption on the users
>desktop may be a selling point to the pointy haired bosses it is a
>downgrade of the encryption protocols and not a direction I would
>recommend.
>
>>> While I have played with "proxy security handling" in the 
>>> past it has been
>>> for out-bound encryption, in-bound signature verification, and policy
>>> enforcement. In-bound decryption & out-bound signing should 
>>> never be done
>>> by anyone but the owner of the private keys.
>
>>The server can have private keys also, and the semantics of the outbound
>>signature is that the server (or organization) signed the message, not
>>the individual.
>
>IMHO this is poor practice. Corporate documents should be signed by the
>author(s) of those documents not some universal company signature. Even
>with corporate entities, one still needs to tie back to individuals in the
>corporation during communications. I may be missing something here, but I
>don't see the value of a generic corporate signature.
>
William,

Have you read draft-ietf-smime-domsec-00.txt?

This contains a section on encryption between servers, and between
individuals and servers. It does not rule out user to user encryption.

I agree with your points on not letting anyone else read your email.
However, organisations want to control the release of messages from their
employees. They want to make sure outgoing messagers do not contain any
sensitive information or viruses. If the sender encrypts his mail using the
recipients key the organisation can not perform any of these checks.

Encrypting and signing using an organisations key rather than an
individuals key reduces the size of the PKI required, and therefore all of
the problems to do with setting up and maintaining a PKI. Plus you are
putting a higher level of credence on the message, its not just coming from
Joe Blogs; its coming from Joe Blogs organisation.

Server to server encryption and signing reduces the cost of buying and
maintaining encryption facilities on the individuals machines. Plus the
burden on the users machine.

You can still tie a message back to the individual by allowing originator
aswell as domain signatures. Infact I recommend the message being signed by
the originator. This gives the organisation the ability to check the
document has not changed, to control who can release messages and a means
of repudination. 

Bill.
________________________________________________________________
William Ottaway,
L323,                        Tel: [phone]
DERA Malvern,                Fax: [phone]
St. Andrews Road,            email: [e-mail]
Malvern,
Worcs,
WR14 3PS



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02512 for ietf-open-pgp-bks; Mon, 28 Sep 1998 05:35:08 -0700 (PDT)
Received: from exeter.ac.uk (hermes.ex.ac.uk [144.173.6.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA02508 for <[e-mail]>; Mon, 28 Sep 1998 05:35:00 -0700 (PDT)
Received: from dialup21 [144.173.6.221] by hermes via ESMTP (NAA15432); Mon, 28 Sep 1998 13:41:17 +0100 (BST)
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id NAA16377; Mon, 28 Sep 1998 13:23:23 +0100
Date: Mon, 28 Sep 1998 13:23:23 +0100
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [e-mail]
Precedence: bulk

William Geiger writes:
> I don't like it. It goes against the concepts of end-to-end
> encryption. If I want to send an encrypted message to someone, I
> want *only* that recipient to be able to read that message, not
> someone down in MIS, not some mail clerk, or god knows who else that
> has access to the local network.
 
This is the way that I think would make sense to set this up.  (I
spent some specing a system to do this for corporate environments).
Bear in mind there is a trade off with some brackets of users: letting
them manage their own keys may be worse than having a machine locked
up in a machine room decrypting for them.  Certainly having a machine
in a machine room AND them both decrypting (super-encrypted traffic)
is more secur than them decrypting on their own.

You have your normal PGP encrypted messages for individuals.  You also
have a outgoing auto-encrypter and an incoming auto-decrypter.

Auto-encrypter:

If the recipient has an individual key (the email adddress is an
individual address) the auto-encrypter encrypts for that individual if
the message is not already encrypted.  You optionally super-encrypt
with the auto-decrypter's public key.

If the recipient does not have an individual key, the message is
encrypted with the recipient's system's auto-decryptor public key.

Auto-decrypter:

Decrypt anything which is decryptable with the auto-decrypter's
private key.

This then is strictly more secure than just PGP on it's own because it
adds security for:

- people who forget to encrypt
- people who don't want to learn how to use encryption
- all messages between sites having the auto-decrypt/auto-encrypt ability

For bonus points you observe that the traffic between the
auto-decrypt/auto-encrypt could just as well be encrypted with forward
secrecy.

You might also observe that installing IPSEC on sending and receiving
mail hub would achieve exactly the same thing (including forward
secrecy).

Mark Grant:
> And as I've mentioned before, this system solves most if not all of the
> problems that CMR claims to solve, without the new problems it creates.

Agree strongly!

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA02054 for ietf-open-pgp-bks; Mon, 28 Sep 1998 04:00:39 -0700 (PDT)
Received: from sirius.infonex.com (sirius.infonex.com [209.75.197.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA02050 for <[e-mail]>; Mon, 28 Sep 1998 04:00:38 -0700 (PDT)
Received: (from nobody@localhost) by sirius.infonex.com (8.8.8/8.8.8) id EAA28698; Mon, 28 Sep 1998 04:07:25 -0700 (PDT)
Date: Mon, 28 Sep 1998 04:07:25 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Sender: [e-mail]
Precedence: bulk

William H. Geiger III [[e-mail]] wrote:
>I don't like it. It goes against the concepts of end-to-end encryption. If
>I want to send an encrypted message to someone, I want *only* that
>recipient to be able to read that message, not someone down in MIS, not
>some mail clerk, or god knows who else that has access to the local
>network. 

I think there's a definite use in corporate-land; just as when I submit an
order to a web-server I use a corporate ordering encryption key, there's
no reason why when I send an order in by email I would use a personal key
rather than a group key. Just as the web-server decrypts the order and
probably stores it in a plaintext file somewhere, the mail server can 
decrypt the order and pass it in plaintext to the first available clerk.

In some cases I want to send mail to a particular person in the company,
but in most cases I just want to send it to a particular department, who
would have to either share a key or have a decryption server. As long as
PGP warns that it's a shared/server-decrypted key (there was talk of 
creating an Open-PGP flag to indicate this, but I don't know whether it
happened) I don't see a problem.

And as I've mentioned before, this system solves most if not all of the
problems that CMR claims to solve, without the new problems it creates.

    Mark



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25442 for ietf-open-pgp-bks; Fri, 25 Sep 1998 14:21:16 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25438; Fri, 25 Sep 1998 14:21:15 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Fri, 25 Sep 1998 14:27:06 PDT
Date: Fri, 25 Sep 1998 14:22:57 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Fri, 25 Sep 1998 15:10:52 -0500" <[e-mail]>
To: "William H. Geiger III" <[e-mail]>
Cc: Ned Freed <[e-mail]>, Graham Klyne <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > I don't know about message/http, but I suspect it would need its own
> > rules. And it isn't clear this issue exists for HTTP anyhow, or that if
> > it does it should be solved this way.

> I am not aware of a message/http. It is my understanding that if you have
> an e-mail message attachment (with headers) that you should use the
> message/rfc822 and then text/http as a MIME part of the attached message
> (with multipart/mixed or multipart/alternative in the message header).

The concept of "message" is a lot more general than e-mail these days. As
are the uses MIME is put to.

Message/http is the media type for an HTTP message. See RFC2068 for details.

> In general message/rfc822 is to be used to signify that a MIME part is a
> message with headers and that the user should reference the header of that
> message for it's context.

An email message, yes. A message in a more general sense, no.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25312 for ietf-open-pgp-bks; Fri, 25 Sep 1998 14:07:01 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25299; Fri, 25 Sep 1998 14:06:34 -0700 (PDT)
Received: from whgiii (dugong35.pcola.gulf.net [205.160.71.98]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id RAA22106; Fri, 25 Sep 1998 17:12:36 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Fri, 25 Sep 1998 16:00:40 -0500
To: "Blake Ramsdell" <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: "Steve Hole" <[e-mail]>, "Ned Freed" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/25/98 
   at 01:47 PM, "Blake Ramsdell" <[e-mail]> said:

>> -----Original Message-----
>> From: William H. Geiger III [mailto:[e-mail]]
>> Sent: Friday, September 25, 1998 1:22 PM
>> To: Steve Hole
>> Cc: Ned Freed; [e-mail]; [e-mail]
>> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
>> 
>> In <[e-mail]>, on 09/18/98 
>>    at 10:55 AM, Steve Hole <[e-mail]> said:
>> 
>> >Also there has been discussion many times in the past of 
>> having "proxy 
>> >security handling" for IMAP servers where the IMAP server handles
>> >decoding encrypted messages on behalf of the client and sending the
>> >decoded content over an encrypted data connection to the 
>> client.   Note
>> >that this is not a  real situation now, but there are lots 
>> of reasons for
>> >people to want this  behaviour in the future and it continues to be
>> >discussed.
>> 
>> IMHO this is *not* a good idea.
>> 
>> The purpose of using end-to-end encryption is to avoid the 
>> use of unknown
>> 3 party systems to relay encrypted data. Decrypting on the server then
>> re-encrypting via different means devalues the original encryption and
>> brings unnecessary exposure of the raw data. It would also 
>> require that
>> the decryption keys of the recipient be stored on the server adding an
>> added level of insecurity.

>The originator can encrypt for the server, which will then decrypt the
>message and send it on to the recipient.  The server does not need to
>have the recipient's private key -- in fact, the recipient may not have a
>keypair at all (only the server).  The value of the original encryption
>is to keep things protected at the message level over the public
>Internet, and then place the plaintext on the local trusted network. 
>This allows for organizations to implement message-level security without
>having to put cryptography on the individual desktops.

I don't like it. It goes against the concepts of end-to-end encryption. If
I want to send an encrypted message to someone, I want *only* that
recipient to be able to read that message, not someone down in MIS, not
some mail clerk, or god knows who else that has access to the local
network. This is the whole point of end-to-end encryption, I don't have to
"trust" any network security, all I have to trust is my local security and
my recipient's local security. While not putting encryption on the users
desktop may be a selling point to the pointy haired bosses it is a
downgrade of the encryption protocols and not a direction I would
recommend.

>> While I have played with "proxy security handling" in the 
>> past it has been
>> for out-bound encryption, in-bound signature verification, and policy
>> enforcement. In-bound decryption & out-bound signing should 
>> never be done
>> by anyone but the owner of the private keys.

>The server can have private keys also, and the semantics of the outbound
>signature is that the server (or organization) signed the message, not
>the individual.

IMHO this is poor practice. Corporate documents should be signed by the
author(s) of those documents not some universal company signature. Even
with corporate entities, one still needs to tie back to individuals in the
corporation during communications. I may be missing something here, but I
don't see the value of a generic corporate signature.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows?  Homey don't play that!

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNgwJTY9Co1n+aLhhAQE96gQAlGhKml9VG7pPUnY+7lDTudU8RN+KFcVF
Ds/LHrL0LEQYQj/y6XZ+ai4Vq4OjLCEQnJTG41qJqUnMhNcNTDR3JbUXyEY4bCta
a4Uw18dOavsbT525YPc+9emOUbl62FAAbjsdnDSLN8ACBwhyD8IuPjDdTloAUTSk
avXbyVsbkX4=
=fkoP
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25116 for ietf-open-pgp-bks; Fri, 25 Sep 1998 13:41:08 -0700 (PDT)
Received: from cane.deming.com (cane.deming.com [208.236.41.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA25112; Fri, 25 Sep 1998 13:41:07 -0700 (PDT)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Fri, 25 Sep 98 13:47:41 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.1960.3) id <TRZ1SYRN>; Fri, 25 Sep 1998 13:47:40 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'William H. Geiger III'" <[e-mail]>, "Steve Hole" <[e-mail]>
cc: "Ned Freed" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)
Date: Fri, 25 Sep 1998 13:47:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 1A12DEE79923-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: William H. Geiger III [mailto:[e-mail]]
> Sent: Friday, September 25, 1998 1:22 PM
> To: Steve Hole
> Cc: Ned Freed; [e-mail]; [e-mail]
> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
> 
> In <[e-mail]>, on 09/18/98 
>    at 10:55 AM, Steve Hole <[e-mail]> said:
> 
> >Also there has been discussion many times in the past of 
> having "proxy 
> >security handling" for IMAP servers where the IMAP server handles
> >decoding encrypted messages on behalf of the client and sending the
> >decoded content over an encrypted data connection to the 
> client.   Note
> >that this is not a  real situation now, but there are lots 
> of reasons for
> >people to want this  behaviour in the future and it continues to be
> >discussed.
> 
> IMHO this is *not* a good idea.
> 
> The purpose of using end-to-end encryption is to avoid the 
> use of unknown
> 3 party systems to relay encrypted data. Decrypting on the server then
> re-encrypting via different means devalues the original encryption and
> brings unnecessary exposure of the raw data. It would also 
> require that
> the decryption keys of the recipient be stored on the server adding an
> added level of insecurity.

The originator can encrypt for the server, which will then decrypt the
message and send it on to the recipient.  The server does not need to
have the recipient's private key -- in fact, the recipient may not have
a keypair at all (only the server).  The value of the original
encryption is to keep things protected at the message level over the
public Internet, and then place the plaintext on the local trusted
network.  This allows for organizations to implement message-level
security without having to put cryptography on the individual desktops.

> While I have played with "proxy security handling" in the 
> past it has been
> for out-bound encryption, in-bound signature verification, and policy
> enforcement. In-bound decryption & out-bound signing should 
> never be done
> by anyone but the owner of the private keys.

The server can have private keys also, and the semantics of the outbound
signature is that the server (or organization) signed the message, not
the individual.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24873 for ietf-open-pgp-bks; Fri, 25 Sep 1998 13:14:52 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24863; Fri, 25 Sep 1998 13:14:46 -0700 (PDT)
Received: from whgiii (dugong35.pcola.gulf.net [205.160.71.98]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id QAA21333; Fri, 25 Sep 1998 16:20:53 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Fri, 25 Sep 1998 15:21:52 -0500
To: Steve Hole <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/18/98 
   at 10:55 AM, Steve Hole <[e-mail]> said:

>Also there has been discussion many times in the past of having "proxy 
>security handling" for IMAP servers where the IMAP server handles
>decoding encrypted messages on behalf of the client and sending the
>decoded content over an encrypted data connection to the client.   Note
>that this is not a  real situation now, but there are lots of reasons for
>people to want this  behaviour in the future and it continues to be
>discussed.

IMHO this is *not* a good idea.

The purpose of using end-to-end encryption is to avoid the use of unknown
3 party systems to relay encrypted data. Decrypting on the server then
re-encrypting via different means devalues the original encryption and
brings unnecessary exposure of the raw data. It would also require that
the decryption keys of the recipient be stored on the server adding an
added level of insecurity.

While I have played with "proxy security handling" in the past it has been
for out-bound encryption, in-bound signature verification, and policy
enforcement. In-bound decryption & out-bound signing should never be done
by anyone but the owner of the private keys.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: The best way to accelerate Windows is at escape velocity.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNgv9Lo9Co1n+aLhhAQEAHAP9FFdmZZD3I8q8R3UgA1Kurzi/GrTOKVkV
jr6t/lSwokNc08qGjusFeu7TwNQHA/dJ/kc60F0whpO0VtLvDc6dW1GopWwJMFSh
p3JhRcltgBdQ/xm/RUbpvdTsaxd5V0vWYV80QzaYqR3EeUz4jVuSJ5ddei2iVvIh
mrrCPdTaVU8=
=ebIz
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24797 for ietf-open-pgp-bks; Fri, 25 Sep 1998 13:03:47 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24774; Fri, 25 Sep 1998 13:00:56 -0700 (PDT)
Received: from whgiii (dugong35.pcola.gulf.net [205.160.71.98]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id QAA21078; Fri, 25 Sep 1998 16:06:54 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Fri, 25 Sep 1998 15:10:52 -0500
To: Ned Freed <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: Graham Klyne <[e-mail]>, Ned Freed <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/24/98 
   at 02:18 AM, Ned Freed <[e-mail]> said:

>I don't know about message/http, but I suspect it would need its own
>rules. And it isn't clear this issue exists for HTTP anyhow, or that if
>it does it should be solved this way.

I am not aware of a message/http. It is my understanding that if you have
an e-mail message attachment (with headers) that you should use the
message/rfc822 and then text/http as a MIME part of the attached message
(with multipart/mixed or multipart/alternative in the message header).

In general message/rfc822 is to be used to signify that a MIME part is a
message with headers and that the user should reference the header of that
message for it's context.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: My best view from a Window was through OS/2.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNgv56I9Co1n+aLhhAQFtWgP5AYc4VB8+BmNGIDFmrPh8fJ46VOl0a5iU
VZAi1K054hzQvSKO9CxpZUg6QmNazTG0f+GsUo7NriwnfdSd4OjWNgKDsgK/g0Tg
RHsUz6+YexthqXSgQqA1UEv/fcuXSSQY3nhUP3/lmDvy0mFBXB38Bxx2JXPm7Y/V
88XJgeIIrNg=
=qx1V
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17300 for ietf-open-pgp-bks; Thu, 24 Sep 1998 00:57:28 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17295; Thu, 24 Sep 1998 00:57:27 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 24 Sep 1998 01:03:31 PDT
Date: Thu, 24 Sep 1998 00:18:57 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Wed, 23 Sep 1998 10:18:05 +0100" <[e-mail]>
To: Graham Klyne <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

> But, I think there is still a question whether this "structural handling"
> information is specific to *just* RFC822.  The premise of my suggestion was
> that the structural handling was more widely applicable.  I am toying with
> a view that the handling may be appropriate to 'message/...' types in general.

It certainly doesn't apply to the subtypes delivery-status or
disposition-notification. This alone makes calling it a general message type
parameter inappropriate. It would at most be a parameter specific message
subtypes could call on if needed.

It can apply to message/external-body, although it only applies indirectly
when message/external-body references a message/rfc822 object.

Message/partial already has well defined structural considerations (indeed,
these rules should serve as a starting point for defining how to recombine
message/rfc822 objects) and needs no such parameter. I actually would have
suggested using a single part message/partial for this were it not for my
belief that the reassembly rules are likely to be different in some ways.

The type message/news should never have been defined -- message/rfc822 was
designed to accomodate news messages despite its name -- and in practice is not
used. 

I don't know about message/http, but I suspect it would need its own rules. And
it isn't clear this issue exists for HTTP anyhow, or that if it does it should
be solved this way.

And that's the entire list of message types.

As a practical matter this sort of structural concern only exists when there's
a set of "outer" headers which are exposed to transport manipulation and hence
cannot be secured by putting them inside of a security enclosure. Now, this
doesn't mean such things cannot appear at an inner level -- this will happen
when someone wants to include an entire message built this way with its
security wrapper intact within another message.

But this does restrict the reasons for using this scheme.  We only have two
outer message types which transports manipulate at present: message/rfc822
(which also covers News) and message/http. I don't want to get into
message/http at the present time. And that leaves message/rfc822.

> A recent discusion I had concerned the actual handling differences between
> 'application/...' and 'message/...' (with reference in part to proposing
> 'application/MIME' vs 'message/MIME').  One view was that 'message/...'
> indicates handling that is expected to be performed by a message handling
> agent, where 'application/...' suggests some external program;  this seems
> to be consistent with the idea that MIME content-types are used for
> dispatching to a handling module or application.

This is a reasonable view. But it doesn't mean that a message/mime object,
should one be defined, would benefit from this sort of structural handling. If
you want to secure such an object all you have to do is put the whole kit and
kaboodle inside of the security enclosure. I see no justifcation for exposing
part of it outside and having to recombine later. (Yes, I realize that people
have on occasion argued that there's value in confidentiality services that
expose, say, the content-type of of the secured material. However, I remain to
be convinced that this is a good idea, let alone that it should be accomplished
by something similar to this.)

> I feel I may be going over some old ground here, and don't wish to restart
> an old debate, but I would be interested in your view.

See above. Also note that if I'm wrong and there's value in using this
mechanism elsewhere, its definition can easily be borrowed in the definition
of another type or subtype at a later date.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18423 for ietf-open-pgp-bks; Wed, 23 Sep 1998 02:12:27 -0700 (PDT)
Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA18415 for <[e-mail]>; Wed, 23 Sep 1998 02:12:26 -0700 (PDT)
Received: (qmail 7809 invoked from network); 23 Sep 1998 09:18:52 -0000
Received: from userp453.uk.uudial.com (HELO GK) (193.149.92.198) by smtp.dial.pipex.com with SMTP; 23 Sep 1998 09:18:52 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 23 Sep 1998 10:18:05 +0100
To: Ned Freed <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 09:32 22/09/98 -0700, Ned Freed wrote:
>> > I personally favor a message/rfc822 parameter, but I can also see a
case for
>> > putting it elsewhere. What do other people think? [...]
>
[...]
>I considered a content-disposition value, but quickly rejected it. My reasons
>include:
>
>(1) This usage is specific to message/rfc822; it doesn't make sense on other
>    content types. Dispositions are supposed to apply regardless of type, and
>    definitely shouldn't be highly type-specific.
>(2) Applications may want to specify a disposition for a message independent
>    of security handling. This results in the one field being used for two
>    things.
>(3) This isn't a disposition per se; it is structural handling information.

I agree -- especially your reason 3 which I realized after my earlier posting.

But, I think there is still a question whether this "structural handling"
information is specific to *just* RFC822.  The premise of my suggestion was
that the structural handling was more widely applicable.  I am toying with
a view that the handling may be appropriate to 'message/...' types in general.

A recent discusion I had concerned the actual handling differences between
'application/...' and 'message/...' (with reference in part to proposing
'application/MIME' vs 'message/MIME').  One view was that 'message/...'
indicates handling that is expected to be performed by a message handling
agent, where 'application/...' suggests some external program;  this seems
to be consistent with the idea that MIME content-types are used for
dispatching to a handling module or application.

I feel I may be going over some old ground here, and don't wish to restart
an old debate, but I would be interested in your view.

#g

------------
Graham Klyne
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28371 for ietf-open-pgp-bks; Tue, 22 Sep 1998 09:30:30 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28367; Tue, 22 Sep 1998 09:30:29 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Tue, 22 Sep 1998 09:36:43 PDT
Date: Tue, 22 Sep 1998 09:32:09 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Tue, 22 Sep 1998 11:13:53 +0100" <[e-mail]>
To: Graham Klyne <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

> > I personally favor a message/rfc822 parameter, but I can also see a case for
> > putting it elsewhere. What do other people think? If there seems to be
> > consensus that this needs to be on message/rfc822, I'd be happy to write
> > a short draft defining such a parameter.

> It sounds as if this might be a role for content-disposition.  In a
> non-RFC822 environment, one might wish to apply the "promotion" principle
> for content types other than message/rfc822, and to encapsulations other
> than signature/encryption.

I considered a content-disposition value, but quickly rejected it. My reasons
include:

(1) This usage is specific to message/rfc822; it doesn't make sense on other
    content types. Dispositions are supposed to apply regardless of type, and
    definitely shouldn't be highly type-specific.
(2) Applications may want to specify a disposition for a message independent
    of security handling. This results in the one field being used for two
    things.
(3) This isn't a disposition per se; it is structural handling information.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA23851 for ietf-open-pgp-bks; Tue, 22 Sep 1998 03:08:23 -0700 (PDT)
Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA23847 for <[e-mail]>; Tue, 22 Sep 1998 03:08:21 -0700 (PDT)
Received: (qmail 22537 invoked from network); 22 Sep 1998 10:14:38 -0000
Received: from userl982.uk.uudial.com (HELO GK) (193.149.77.33) by smtp.dial.pipex.com with SMTP; 22 Sep 1998 10:14:38 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 22 Sep 1998 11:13:53 +0100
To: Ned Freed <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 15:47 17/09/98 -0700, Ned Freed wrote:
>> I'd like to see a convention established for interpreting the
>> message/rfc822 type in this way, possibly when accompanied by some
>> other syntax.
>
>I agree that this would be useful functionality -- I've suggested adding
>it several times in the past, but was never able to get much support
>for it.
>
>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the 
>MIME message/rfc822 content.
>
>I personally favor a message/rfc822 parameter, but I can also see a case for
>putting it elsewhere. What do other people think? If there seems to be
>consensus that this needs to be on message/rfc822, I'd be happy to write
>a short draft defining such a parameter.

It sounds as if this might be a role for content-disposition.  In a
non-RFC822 environment, one might wish to apply the "promotion" principle
for content types other than message/rfc822, and to encapsulations other
than signature/encryption.

#g

------------
Graham Klyne
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22634 for ietf-open-pgp-bks; Fri, 18 Sep 1998 08:49:31 -0700 (PDT)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22624; Fri, 18 Sep 1998 08:49:25 -0700 (PDT)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (2.0.4/SMS 2.0.4) with ESMTP id JAA24473; Fri, 18 Sep 1998 09:55:26 -0600
From: Steve Hole <[e-mail]>
Date: Fri, 18 Sep 1998 09:55:19 -0600
To: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> "Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Simeon for Win32 Version Mercury a8+ Build (13)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9809180955.F; protocol="application/pgp-signature"; micalg=pgp-sha1
Sender: [e-mail]
Precedence: bulk

--Part9809180955.F
Content-Type: Text/PLAIN; CHARSET=US-ASCII


On Thu, 17 Sep 1998 15:47:36 -0700 (PDT) Ned Freed <[e-mail]>
wrote:

> I personally favor a message/rfc822 parameter, but I can also see a case for
> putting it elsewhere. What do other people think? If there seems to be
> consensus that this needs to be on message/rfc822, I'd be happy to write
> a short draft defining such a parameter.

So do I.   There are some reasonably complex interplays between cached and 
displayed structures in the presence of security - especially in an IMAP4 mail 
client.   Clients that cache MIME structures will often do things like cache
overlays for security multiparts so that their UI code doesn't have to know
anything about security -- that is all handled at the MIME abstraction level.
Also there has been discussion many times in the past of having "proxy 
security handling" for IMAP servers where the IMAP server handles decoding
encrypted messages on behalf of the client and sending the decoded content
over an encrypted data connection to the client.   Note that this is not a 
real situation now, but there are lots of reasons for people to want this 
behaviour in the future and it continues to be discussed.

The message/rfc822 solution would work transparently in the cases described 
above.   If the parameter is attached to the security multiparts then it is
possible that it will be occluded or lost by an MUA in the act of removing 
the security.   Putting it at the message/rfc822 level means that it will
always be exposed to UI code and the UI can decide how to "cook" the display
to show the right thing. 

Cheers. 

---  
Steve Hole                           
The Esys Corporation
Mailto:[e-mail]  
Phone:[phone]

--Part9809180955.F
Content-Type: Application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version)

iQA/AwUBNgKCa9i5Jj9Fn5KMEQL9TQCeMIoS1oWmLI78DdHpMmI7RwP4XfAAn0XW
R/tXWkOISSxo7q9czbLITPPZ
=gcCK
-----END PGP SIGNATURE-----

--Part9809180955.F--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21176 for ietf-open-pgp-bks; Fri, 18 Sep 1998 05:21:11 -0700 (PDT)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21154; Fri, 18 Sep 1998 05:20:41 -0700 (PDT)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with SMTP id NAA17018; Fri, 18 Sep 1998 13:26:37 +0100 (BST)
Message-ID: <[e-mail]>
Date: Fri, 18 Sep 1998 13:24:02 +0100
To: [e-mail], [e-mail]
From: Ian Bell <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
References: <hmnp$QAJ5NA2IA$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.00  <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: [e-mail]
Precedence: bulk

In article <[e-mail]>, Ned Freed
<[e-mail]> writes
>> (Apologies if this has been done to death in the past - I can imagine
>> Ned sighing about protracted discussions prior to RFC1847 - but I
>> couldn't find any discussion in the archives)
>
>> RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
>> allow MIME headers to be protected by the encryption process. Was there
>> any discussion during the preparation of RFC1847 about the possibility /
>> desirability / feasibility of allowing general RFC822 headers to be
>> included in the encrypted part of the message?
>
>There were extensive discussions of this. I probably have several hundred
>messages archived on this topic, and there were also WG discussions and several
>private meetings where the design team covered this area exhaustively.
>

Thought as much :-)

>And all these activities are the rule, not the exception. And it is far more
>likely to happen to fields it makes sense to sign, such as subject, to/cc/bcc,
>comments, etc. than to any others.

I was just thinking of encryption, but of course a scheme that covers
signing headers as well as encrypting them is so much the better.

>
>> Could (and should) any replacements for RFC2015 and RFC2311 be amended
>> to allow RFC822 headers to be sent encrypted, and for the decryption
>> process to swap any encrypted headers found with the corresponding
>> headers in the actual message?
>
>There is no need to do this. All you need to do is use MIME encapsulation
>to put the real headers into the body of the message.
>

My problem with that was that the intent of encapsulation would not be
clear. However, putting a parameter on the message/rfc822 to make it
clear seems to solve the problem completely.

Later, you wrote:

>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the 
>MIME message/rfc822 content.

Putting the parameter at the encryption header level announces that
there are hidden headers that will be substituted, though maybe that's
too minor a security breach to worry about.

A parameter at the message/rfc822 header level would in one extension
cover signed, encrypted, encrypted-then-signed and encrypted-and-signed
messages, and would even allow messages to be resent without using
Resent- headers if anyone has a use for that!

>
>-- I've suggested adding
>it several times in the past, but was never able to get much support
>for it.
>

Hopefully this thread will have demonstrated sufficient support.

-- 
Ian Bell                                           T U R N P I K E  Ltd


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA08268 for ietf-open-pgp-bks; Thu, 17 Sep 1998 22:54:16 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA08263; Thu, 17 Sep 1998 22:54:15 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 17 Sep 1998 22:59:08 PDT
Date: Thu, 17 Sep 1998 22:55:50 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Thu, 17 Sep 1998 17:20:09 -0700" <v04101908b227569e6d17@[129.46.172.254]>
To: "John  W. Noerenberg" <[e-mail]>
Cc: Ned Freed <[e-mail]>, Hal Finney <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > Its clear that this indicator has to be on the "inside", since you want the
> > signature to be able to cover it. This then begs the question of whether
> > it should be an attribute of the signature/encryption facility or of the
> > MIME message/rfc822 content.

> Putting the indicator the header exposes information about the message --
> the decrypted contents of the message is supposed to replace the headers of
> the message.  Keeping it inside doesn't reveal this.

The header indicator would be on the _inner_ header, not the outer one.
This is no more revealing than anything else that's "inside".

> > I personally favor a message/rfc822 parameter, but I can also see a case for
> > putting it elsewhere. What do other people think? If there seems to be
> > consensus that this needs to be on message/rfc822, I'd be happy to write
> > a short draft defining such a parameter.

> Maybe only the truly paranoid care about this, but it does violate a
> security principle.  Putting it inside the ciphertext probably complicates
> the MUA's job, but I don't think it's a particularly daunting complication.

I'm talking about putting it inside the ciphertext (assuming encyption
is used, of course).

Amusingly enough, we've had objections in the past from security experts saying
that putting the MIME labelling of the encrypted content inside the encryption
is a Bad Thing. (Of course this didn't result in any changes.) So much for
agreement in principle ;-)

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA06281 for ietf-open-pgp-bks; Thu, 17 Sep 1998 22:27:58 -0700 (PDT)
Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA06256; Thu, 17 Sep 1998 22:27:51 -0700 (PDT)
Received: from anonymous (slip129-37-235-151.ca.us.ibm.net [129.37.235.151]) by out1.ibm.net (8.8.5/8.6.9) with ESMTP id FAA08378; Fri, 18 Sep 1998 05:33:51 GMT
Message-Id: <[e-mail]>
From: "Tom Phinney" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Date: Thu, 17 Sep 1998 22:33:07 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

From: [e-mail]

> > Could (and should) any replacements for RFC2015 and RFC2311 be
amended
> > to allow RFC822 headers to be sent encrypted, and for the
decryption
> > process to swap any encrypted headers found with the corresponding
> > headers in the actual message?
>
> To my best knowledge, there is a non-official scheme to do this. Here
> is an example:
>
> X-PGP-Sig: 2.6.3ia Subject,From,X-Mailer
>        
iQCVAwUBM84wngE7m572a9utAQETEgQAwcL38QVdZbkHuW4Mblmje17deuI85R1j
>        
4yGiDlb1enRDSUyGiLCmk8YphNDiLdKKlMV3Z0opzREUW9Q+sb8fr5s1QXMJhvXs
>        
7hi7s4+V00rjgbqbqXVNiajKiKfVxd7JTRfe0UIZuOljnURP1ZCMlSRD1rDoCEAg
>         1vunQv6QYj4=
>         =hvn0
>
> This is a header field to be stored in a header, mixed with fields to
> be proteced such as Subject, From, and X-Mailer.
>
> If you are interested, I will ack the author to explain his
> experiences.


Of course, there's already a mature technology which uses PGP to 
encapsulate message headers and contents, which replace the original 
message headers and contents after decryption.  It's used in the Type 1

Cypherpunk remailers.  :-)

I'm not proposing that you should use this; it doesn't seem
appropriate.  
But it is worth studying as a reference technology which achieves the 
privacy goals being discussed her.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA03080 for ietf-open-pgp-bks; Thu, 17 Sep 1998 21:56:19 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03069; Thu, 17 Sep 1998 21:55:46 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA27879; Fri, 18 Sep 1998 14:01:08 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA07769; Fri, 18 Sep 1998 14:01:07 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA22374; Fri, 18 Sep 1998 14:01:07 +0900 (JST)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Thu, 17 Sep 1998 11:02:49 +0100" <hmnp$QAJ5NA2IA$[e-mail]>
References: <hmnp$QAJ5NA2IA$[e-mail]>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Fri, 18 Sep 1998 13:00:21 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 28
Sender: [e-mail]
Precedence: bulk

Ian,

From: Ian Bell <[e-mail]>
Subject: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Date: Thu, 17 Sep 1998 11:02:49 +0100

> Could (and should) any replacements for RFC2015 and RFC2311 be amended
> to allow RFC822 headers to be sent encrypted, and for the decryption
> process to swap any encrypted headers found with the corresponding
> headers in the actual message?

To my best knowledge, there is a non-official scheme to do this. Here
is an example:

X-PGP-Sig: 2.6.3ia Subject,From,X-Mailer
        iQCVAwUBM84wngE7m572a9utAQETEgQAwcL38QVdZbkHuW4Mblmje17deuI85R1j
        4yGiDlb1enRDSUyGiLCmk8YphNDiLdKKlMV3Z0opzREUW9Q+sb8fr5s1QXMJhvXs
        7hi7s4+V00rjgbqbqXVNiajKiKfVxd7JTRfe0UIZuOljnURP1ZCMlSRD1rDoCEAg
        1vunQv6QYj4=
        =hvn0

This is a header field to be stored in a header, mixed with fields to
be proteced such as Subject, From, and X-Mailer.

If you are interested, I will ack the author to explain his
experiences.

--Kazu


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28048 for ietf-open-pgp-bks; Thu, 17 Sep 1998 18:47:14 -0700 (PDT)
Received: from candle.brasslantern.com ([e-mail] [206.155.48.241]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28029; Thu, 17 Sep 1998 18:46:52 -0700 (PDT)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id SAA02549; Thu, 17 Sep 1998 18:51:45 -0700
From: "Bart Schaefer" <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 17 Sep 1998 18:51:45 -0700
In-Reply-To: <v04101908b227569e6d17@[129.46.172.254]>
Comments: In reply to "John  W. Noerenberg" <[e-mail]> "Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages" (Sep 17,  5:20pm)
References: "Your message dated Thu  17 Sep 1998 12:14:46 -0700" <[e-mail]>  <v04101908b227569e6d17@[129.46.172.254]>
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: "John  W. Noerenberg" <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

On Sep 17,  5:20pm, John  W. Noerenberg wrote:
} Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
}
} At 3:47 PM -0700 9/17/98, Ned Freed wrote:
} >Its clear that this indicator has to be on the "inside", since you want the
} >signature to be able to cover it. This then begs the question of whether
} >it should be an attribute of the signature/encryption facility or of the
} >MIME message/rfc822 content.
} 
} Putting the indicator the header exposes information about the message -- 
} the decrypted contents of the message is supposed to replace the headers of 
} the message.  Keeping it inside doesn't reveal this.

I think you misunderstand, John.  I believe the suggested format is for
the outer message to specify an encrypted Content-Type, and then for the
encrypted content to be a message/rfc822 with a parameter specifying that
its headers should replace the enclosing message's headers only after the
inner message is successfully decrypted.

This hides the parameter (indeed, it hides the entire nested message/rfc822
structure) inside the ciphertext, but allows a sufficiently clever UA to
present the contained message in place of the top-level message.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27549 for ietf-open-pgp-bks; Thu, 17 Sep 1998 17:22:37 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27539; Thu, 17 Sep 1998 17:22:28 -0700 (PDT)
Received: from [129.46.172.254] (jnoerenberg-mac.qualcomm.com [129.46.172.254]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA24259; Thu, 17 Sep 1998 17:27:12 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <v04101908b227569e6d17@[129.46.172.254]>
In-Reply-To: <[e-mail]>
References: "Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
X-Mailer: Eudora [Macintosh version 4.1b25-10.98]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Thu, 17 Sep 1998 17:20:09 -0700
To: Ned Freed <[e-mail]>
From: "John  W. Noerenberg" <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: Hal Finney <[e-mail]>, [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

At 3:47 PM -0700 9/17/98, Ned Freed wrote:
>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the
>MIME message/rfc822 content.

Putting the indicator the header exposes information about the message -- 
the decrypted contents of the message is supposed to replace the headers of 
the message.  Keeping it inside doesn't reveal this.

>I personally favor a message/rfc822 parameter, but I can also see a case for
>putting it elsewhere. What do other people think? If there seems to be
>consensus that this needs to be on message/rfc822, I'd be happy to write
>a short draft defining such a parameter.

Maybe only the truly paranoid care about this, but it does violate a 
security principle.  Putting it inside the ciphertext probably complicates 
the MUA's job, but I don't think it's a particularly daunting complication.

john noerenberg
[e-mail]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27134 for ietf-open-pgp-bks; Thu, 17 Sep 1998 16:36:20 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA27130; Thu, 17 Sep 1998 16:36:19 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 17 Sep 1998 16:41:48 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-Reply-To: <[e-mail]>
References: <"Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:47 PM 9/17/98 -0700, Ned Freed wrote:
>I personally favor a message/rfc822 parameter, but I can also see a case for
>putting it elsewhere. What do other people think? If there seems to be
>consensus that this needs to be on message/rfc822, I'd be happy to write
>a short draft defining such a parameter.

Given that OpenPGP is about to go to IESG last call in days, and S/MIME is
in it's last throes, and that the two groups are sure to do things
differently :-), I think a message/rfc822 parameter would be best.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26900 for ietf-open-pgp-bks; Thu, 17 Sep 1998 16:11:14 -0700 (PDT)
Received: from candle.brasslantern.com ([e-mail] [206.155.48.241]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26890; Thu, 17 Sep 1998 16:11:00 -0700 (PDT)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id QAA02063; Thu, 17 Sep 1998 16:16:44 -0700
From: "Bart Schaefer" <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 17 Sep 1998 16:16:44 -0700
In-Reply-To: <[e-mail]>
Comments: In reply to Ned Freed <[e-mail]> "Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages" (Sep 17,  3:47pm)
References: <[e-mail]>
X-Mailer: Z-Mail Lite (5.0.0 30July97)
To: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

On Sep 17,  3:47pm, Ned Freed wrote:
> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
> > I'd like to see a convention established for interpreting the
> > message/rfc822 type in this way, possibly when accompanied by some
> > other syntax.
> 
> I personally favor a message/rfc822 parameter, but I can also see a case for
> putting it elsewhere. What do other people think? If there seems to be
> consensus that this needs to be on message/rfc822, I'd be happy to write
> a short draft defining such a parameter.

I think such a parameter would be useful in other situations besides
signed message content, so I support defining it in message/rfc822 rather
than in the signature.

If you do write a draft, please make mention of the interpretation of
this parameter when the message/rfc822 is included by reference via
message/external-body.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26695 for ietf-open-pgp-bks; Thu, 17 Sep 1998 15:47:23 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26691; Thu, 17 Sep 1998 15:47:22 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 17 Sep 1998 15:52:20 PDT
Date: Thu, 17 Sep 1998 15:47:36 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Thu, 17 Sep 1998 12:14:46 -0700" <[e-mail]>
To: Hal Finney <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

> I'd like to see a convention established for interpreting the
> message/rfc822 type in this way, possibly when accompanied by some
> other syntax.

I agree that this would be useful functionality -- I've suggested adding
it several times in the past, but was never able to get much support
for it.

Its clear that this indicator has to be on the "inside", since you want the
signature to be able to cover it. This then begs the question of whether
it should be an attribute of the signature/encryption facility or of the 
MIME message/rfc822 content.

I personally favor a message/rfc822 parameter, but I can also see a case for
putting it elsewhere. What do other people think? If there seems to be
consensus that this needs to be on message/rfc822, I'd be happy to write
a short draft defining such a parameter.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25721 for ietf-open-pgp-bks; Thu, 17 Sep 1998 13:33:48 -0700 (PDT)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25717; Thu, 17 Sep 1998 13:33:47 -0700 (PDT)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.1/8.9.1) with ESMTP id NAA24579; Thu, 17 Sep 1998 13:37:11 -0700 (PDT)
Received: (from hal@localhost) by hal.sb.rain.org (8.7.4/8.7.3) id MAA01954; Thu, 17 Sep 1998 12:14:46 -0700
Date: Thu, 17 Sep 1998 12:14:46 -0700
From: Hal Finney <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Sender: [e-mail]
Precedence: bulk

Ian Bell writes:

> It would be good if there were an interoperable way of making the
> stored, decrypted message reflect the message the author would have
> liked to send in the first place. It would be particularly nice if the
> author could transmit the intended subject of a message when this may be
> too sensitive to put in the open message headers.

The Subject header would be one which would benefit most from encryption.
Subjects leak information about message contents.  Used carelessly, they
may expose the meaning of the message, or at least indicate which messages
contain sensitive information that might be targetted by an attacker.

However, replacing the Subject header only when the message is stored
for later reference misses another possible benefit.  Many archived
messages are never even referred to again.

What would be even better would be if the user's mail software decrypted
all messages in the incoming mailbox and "promoted" message/rfc822
headers up to the message header level.  Then the encrypted message
subjects could be displayed before the messages are read.  Busy email
users often use Subject headers to prioritize their mail handling.
But to make use of this capability, decrypted Subject headers must be
presented by the mail software beforehand.

I'd like to see a convention established for interpreting the
message/rfc822 type in this way, possibly when accompanied by some
other syntax.

Hal


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24467 for ietf-open-pgp-bks; Thu, 17 Sep 1998 11:12:30 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24462; Thu, 17 Sep 1998 11:12:29 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <[e-mail]>; Thu, 17 Sep 1998 11:17:51 PDT
Date: Thu, 17 Sep 1998 11:04:15 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
In-reply-to: "Your message dated Thu, 17 Sep 1998 11:02:49 +0100" <hmnp$QAJ5NA2IA$[e-mail]>
To: Ian Bell <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

> (Apologies if this has been done to death in the past - I can imagine
> Ned sighing about protracted discussions prior to RFC1847 - but I
> couldn't find any discussion in the archives)

> RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
> allow MIME headers to be protected by the encryption process. Was there
> any discussion during the preparation of RFC1847 about the possibility /
> desirability / feasibility of allowing general RFC822 headers to be
> included in the encrypted part of the message?

There were extensive discussions of this. I probably have several hundred
messages archived on this topic, and there were also WG discussions and several
private meetings where the design team covered this area exhaustively.

The basic conclusion was (and is) that this dog doesn't hunt and cannot be made
to hunt. The problem is that message headers are routinely rewritten by
intervening MTAs as messages are transferred via SMTP. They are refolded,
reordered, addresses are converted from one form to another, encoded
words are added or removed, entire fields are added or deleted.

And all these activities are the rule, not the exception. And it is far more
likely to happen to fields it makes sense to sign, such as subject, to/cc/bcc,
comments, etc. than to any others.

In short, if you want to keep the transports from modifying things, you cannot
put them in the primary header. You either have to put them in the body. And
given this, MIME provides the obvious means to do this if that's what you're
after -- nested messages.

> The most obvious candidates for headers to be encrypted along with the
> MIME headers would be Subject: and Disposition-Notification-To: (the
> subject the sender may have intended to use may be too sensitive to use
> as the subject of the open message: the sender may want any MDN to be
> sent only when the message is decrypted), though cases could probably be
> made for just about any RFC822 header.

> Could (and should) any replacements for RFC2015 and RFC2311 be amended
> to allow RFC822 headers to be sent encrypted, and for the decryption
> process to swap any encrypted headers found with the corresponding
> headers in the actual message?

There is no need to do this. All you need to do is use MIME encapsulation
to put the real headers into the body of the message.

One thing that would be nice is if there was a way to say in the signature
information that the inner message is actually supposed to replace the outer
container message. (This could also be done as a parameter to message/rfc822
if need be, although there are arguments for doing it in the signature.

There is one other thing that is missing, however, and that is a means of
encapsulating the entire message including the envelope. There are many
applications where the envelope itself is sensitive and needs end-to-end
protection.

And there is a proposal on the table to deal with this:
draft-freed-bsmtp-02.txt. This defines envelope encapsulation and the semantics
that necessarily follow from doing it.

> As availability of encryption software becomes more widespread, many
> end-users may find SMIME/PGP most useful as simply a transport security
> mechanism rather than a way of securely storing messages. In any case,
> MUAs implementing PGP or S/MIME probably already allow the user to save
> the decrypted version of a message.

Sure.

> It would be good if there were an interoperable way of making the
> stored, decrypted message reflect the message the author would have
> liked to send in the first place. It would be particularly nice if the
> author could transmit the intended subject of a message when this may be
> too sensitive to put in the open message headers.

See above.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21963 for ietf-open-pgp-bks; Thu, 17 Sep 1998 05:40:02 -0700 (PDT)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21944; Thu, 17 Sep 1998 05:36:57 -0700 (PDT)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with SMTP id NAA01244; Thu, 17 Sep 1998 13:42:48 +0100 (BST)
Message-ID: <[e-mail]>
Date: Thu, 17 Sep 1998 13:40:49 +0100
To: [e-mail], [e-mail]
From: Ian Bell <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.00  <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: [e-mail]
Precedence: bulk

In article <[e-mail]>, Lindsay Mathieson
<[e-mail]> writes
>
>>RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
>>allow MIME headers to be protected by the encryption process. Was there
>>any discussion during the preparation of RFC1847 about the possibility
>>/ desirability / feasibility of allowing general RFC822 headers to
>>be included in the encrypted part of the message?
>
>Its quite acceptable to generate your message as a message/rfc822 mime type
>and encrypt the entire body.

I had considered that (and had intended to mention it), but using
message/rfc822 doesn't quite give the same effect. In fact it wouldn't
work at all in the case of the Disposition-Notification-To header unless
the RFCs were modified.

The MIME headers within the encrypted body _replace_ the MIME headers in
the header of the message actually received, whereas the headers within
a message/rfc822 body don't. It would not be clear to the receiving MUA
whether the message/rfc822 were to be regarded as a forwarded message or
to be regarded as the original, fully encrypted, message.

Allowing RFC822 headers to be encrypted alongside the MIME headers would
unambiguously indicate that those headers were intended to be part of
the original message.

-- 
Ian Bell                                           T U R N P I K E  Ltd


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21442 for ietf-open-pgp-bks; Thu, 17 Sep 1998 04:01:04 -0700 (PDT)
Received: from enterprise.powerup.com.au ([e-mail] [203.32.8.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA21438 for <[e-mail]>; Thu, 17 Sep 1998 04:01:02 -0700 (PDT)
Message-Id: <[e-mail]>
Received: (qmail 1929 invoked from network); 17 Sep 1998 11:06:57 -0000
Received: from ts5547.powerup.com.au (HELO lindsay) (202.139.238.47) by enterprise.powerup.com.au with SMTP; 17 Sep 1998 11:06:57 -0000
Date: 17 Sep 1998 22:9:46 GMT
From: Lindsay Mathieson <[e-mail]>
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
To: Ian Bell <[e-mail]>, IETF OpenPGP <[e-mail]>
X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.8 Preview 2
Sender: [e-mail]
Precedence: bulk

>RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
>allow MIME headers to be protected by the encryption process. Was there
>any discussion during the preparation of RFC1847 about the possibility
>/ desirability / feasibility of allowing general RFC822 headers to
>be included in the encrypted part of the message?

Its quite acceptable to generate your message as a message/rfc822 mime type
and encrypt the entire body.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.8 Preview 2, on September 17, 1998, in
Win95 4.0
	http://www.blackpaw.com/





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19360 for ietf-open-pgp-bks; Thu, 17 Sep 1998 03:02:13 -0700 (PDT)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19308; Thu, 17 Sep 1998 02:59:31 -0700 (PDT)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with SMTP id LAA21050; Thu, 17 Sep 1998 11:05:16 +0100 (BST)
Message-ID: <hmnp$QAJ5NA2IA$[e-mail]>
Date: Thu, 17 Sep 1998 11:02:49 +0100
To: [e-mail], [e-mail]
From: Ian Bell <[e-mail]>
Subject: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
MIME-Version: 1.0
X-Mailer: Turnpike (32) Version 4.00  <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: [e-mail]
Precedence: bulk

(Apologies if this has been done to death in the past - I can imagine
Ned sighing about protracted discussions prior to RFC1847 - but I
couldn't find any discussion in the archives)

RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
allow MIME headers to be protected by the encryption process. Was there
any discussion during the preparation of RFC1847 about the possibility /
desirability / feasibility of allowing general RFC822 headers to be
included in the encrypted part of the message?

The most obvious candidates for headers to be encrypted along with the
MIME headers would be Subject: and Disposition-Notification-To: (the
subject the sender may have intended to use may be too sensitive to use
as the subject of the open message: the sender may want any MDN to be
sent only when the message is decrypted), though cases could probably be
made for just about any RFC822 header.

Could (and should) any replacements for RFC2015 and RFC2311 be amended
to allow RFC822 headers to be sent encrypted, and for the decryption
process to swap any encrypted headers found with the corresponding
headers in the actual message?


As availability of encryption software becomes more widespread, many
end-users may find SMIME/PGP most useful as simply a transport security
mechanism rather than a way of securely storing messages. In any case,
MUAs implementing PGP or S/MIME probably already allow the user to save
the decrypted version of a message.

It would be good if there were an interoperable way of making the
stored, decrypted message reflect the message the author would have
liked to send in the first place. It would be particularly nice if the
author could transmit the intended subject of a message when this may be
too sensitive to put in the open message headers.

-- 
Ian Bell                                           T U R N P I K E  Ltd


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14508 for ietf-open-pgp-bks; Tue, 15 Sep 1998 15:37:13 -0700 (PDT)
Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14504 for <[e-mail]>; Tue, 15 Sep 1998 15:37:11 -0700 (PDT)
Received: from paris.public.uni-hamburg.de (max2-094.public.uni-hamburg.de [134.100.45.94]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id AAA20700 for <[e-mail]>; Wed, 16 Sep 1998 00:42:49 +0200
Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m0zJ3T7-0003b7C; Wed, 16 Sep 98 00:21 +0200
Message-Id: <[e-mail]>
Date: Wed, 16 Sep 98 00:21 +0200
From: [e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [e-mail]
Subject: error in draft 07, section 5.2.1
In-Reply-To: <[e-mail]>
Organization: HR13
Sender: [e-mail]
Precedence: bulk

|   0x01: Signature of a canonical text document.
|       Typically, this means the signer owns it, created it, or
|       certifies that it has not been modified.  The signature is
|       calculated over the text data with its line endings converted to
|       <CR><LF> and trailing blanks removed.

Trailing blanks are removed _only_ for cleartext signatures, in the
transformation described in section 7.1. Otherwise (for signatures
contained in a PGP message, and for detached signatures) they are part
of the signature.

BTW, there's no proper definition of detached signatures in the draft.
They probably should be mentioned in section 10 because they are used
for PGP/MIME.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA24281 for ietf-open-pgp-bks; Sun, 13 Sep 1998 22:57:27 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA24277 for <[e-mail]>; Sun, 13 Sep 1998 22:57:26 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA22676; Mon, 14 Sep 1998 15:03:04 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA27388; Mon, 14 Sep 1998 15:03:03 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA00713; Mon, 14 Sep 1998 15:03:03 +0900 (JST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: the micalg parameter
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Thu, 10 Sep 1998 11:29:56 +0200" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93pre4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 14 Sep 1998 14:02:22 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 21
Sender: [e-mail]
Precedence: bulk

From: Thomas Roessler <[e-mail]>
Subject: Re: the micalg parameter
Date: Thu, 10 Sep 1998 11:29:56 +0200

> Now, why do you think that a mis-match being illegal means
> that an implementation can't be robust and ignore the
> parameter in this case?  The behaviour is simply undefined, so 
> the choice is yours - conform to the GIGO principle or try  
> to handle things smoothly.

There is a big difference between undefined and implementation choice.

The former means ambiguous. 

The latter menas, yes, you clearly defined. If we will define its
semantics as implementation choice after discussions, it's fine to me.

Personally, I dislike to define it as implementation choice. This is a
signature service, so I think we should share a single semantics.

--Kazu


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA23852 for ietf-open-pgp-bks; Sun, 13 Sep 1998 22:50:08 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA23848 for <[e-mail]>; Sun, 13 Sep 1998 22:50:06 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA22488; Mon, 14 Sep 1998 14:55:32 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA26481; Mon, 14 Sep 1998 14:55:31 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA29722; Mon, 14 Sep 1998 14:55:31 +0900 (JST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Revising RFC 2015
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Thu, 10 Sep 1998 08:55:35 -0600" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93pre4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 14 Sep 1998 13:54:51 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 25
Sender: [e-mail]
Precedence: bulk

From: Steve Hole <[e-mail]>
Subject: Re: Revising RFC 2015
Date: Thu, 10 Sep 1998 08:55:35 -0600

> Being one of the very few people that has implemented both PGP/MIME
> and S/MIME into their mail products, I can tell you absolutely that
> the use of Multipart/Encrypted is a MUST.  Especially for IMAP4
> mailers where access to the MIME body structure allows a client to
> do intelligent things with an encrypted body part.  You are simply
> wrong on this count.  I would fight to the death any attempt to
> remove multipart/encrypted from the specification.

I said, "this is just for your information". I didn't propose to
introduce such a drastic change to PGP/MIME.

BTW. I have a couple of questions to you.

(1) Why do you think multipart/encrypted is a MUST? What you do mean
intelligent things? I'm very much curious about them. Could you please
explain more concretely?

(2) S/MIME doesn't use multipart/encrypted. Being one of the few
people, what do you think of it?

--Kazu


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA20673 for ietf-open-pgp-bks; Fri, 11 Sep 1998 06:50:37 -0700 (PDT)
Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA20669 for <[e-mail]>; Fri, 11 Sep 1998 06:50:35 -0700 (PDT)
Received: by brickwall.ceddec.com id <43013>; Fri, 11 Sep 1998 09:54:45 -0400
Date: Fri, 11 Sep 1998 09:55:58 -0400
From: [e-mail]
X-Sender: nobody@mars
To: Thorsten Maly <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Documentation of PGP 2.6.x and PGP 5.x Keyring File Format
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Fri, 11 Sep 1998, Thorsten Maly wrote:

> Does anybody know where I can find documentation/developer notes on the 
> Keyring File Format for PGP 2.6.x or PGP 5.x. This aspect does not seem
> to 
> be covered in the draft, nor could I find any information on the web. 

The overall format is in 11.1:

----------
11. Enhanced Key Formats

11.1. Key Structures

   The format of an OpenPGP V3 key is as follows.  Entries in square
   brackets are optional and ellipses indicate repetition.

           RSA Public Key
              [Revocation Self Signature]
               User ID [Signature ...]
              [User ID [Signature ...] ...]

   Each signature certifies the RSA public key and the preceding user
   ID. The RSA public key can have many user IDs and each user ID can
   have many signatures.

   The format of an OpenPGP V4 key that uses two public keys is similar
   except that the other keys are added to the end as 'subkeys' of the
   primary key.

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

---------

A keyring file is just a bunch of these concatenated together, i.e.
primary keys followed by the other subpackets.

Also see:

http://www.chem.swin.edu.au/~graeme/pgformat/

particularly public key ring overall structure.  There are postscript
versions of this on the net elsewhere, but I don't have a URL handy.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19198 for ietf-open-pgp-bks; Fri, 11 Sep 1998 03:17:18 -0700 (PDT)
Received: from faust27-s.rz.uni-frankfurt.de ([e-mail] [141.2.149.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA19194 for <[e-mail]>; Fri, 11 Sep 1998 03:17:13 -0700 (PDT)
Received: from NAFp2-048.rz.uni-frankfurt.de by faust15-eth.rz.uni-frankfurt.de  with Local SMTP (PP); Fri, 11 Sep 1998 12:21:59 +0000
Received: by NAFp2-048.rz.uni-frankfurt.de with Microsoft Mail  id <[e-mail]>; Fri, 11 Sep 1998 12:18:56 +0200
Message-ID: <[e-mail]>
From: Thorsten Maly <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Documentation of PGP 2.6.x and PGP 5.x Keyring File Format
Date: Fri, 11 Sep 1998 12:18:50 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Does anybody know where I can find documentation/developer notes on the 
Keyring File Format for PGP 2.6.x or PGP 5.x. This aspect does not seem
to 
be covered in the draft, nor could I find any information on the web. 

Thanks in advance for any help.

Thorsten Maly
[e-mail]





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26657 for ietf-open-pgp-bks; Thu, 10 Sep 1998 17:14:22 -0700 (PDT)
Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26653 for <[e-mail]>; Thu, 10 Sep 1998 17:14:20 -0700 (PDT)
Received: from paris.public.uni-hamburg.de (max1-102.public.uni-hamburg.de [134.100.43.102]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id CAA78724 for <[e-mail]>; Fri, 11 Sep 1998 02:19:43 +0200
Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m0zHGty-0003b7C; Fri, 11 Sep 98 02:17 +0200
Message-Id: <[e-mail]>
Date: Fri, 11 Sep 98 02:17 +0200
From: [e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [e-mail]
Subject: Re: Bug: Public-Key Encrypted Session Key Packets?
In-Reply-To: <[e-mail]>
Organization: HR13
Sender: [e-mail]
Precedence: bulk

The description of Public-Key Encrypted Session Key Packets is still
flawed in the 07 draft, as Ian Brown noted in a comment to the
previous draft.

>>5.1. Public-Key Encrypted Session Key Packets (Tag 1)
>>...
>>a two-octet checksum is appended which is equal to the
>>sum of the preceding octets, including the algorithm
>>identifier and session key, modulo 65536

The checksum is over the session key only, *not* including the
algorithm identifier.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22280 for ietf-open-pgp-bks; Thu, 10 Sep 1998 07:51:32 -0700 (PDT)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22276 for <[e-mail]>; Thu, 10 Sep 1998 07:51:31 -0700 (PDT)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (2.0.4/SMS 2.0.4) with ESMTP id IAA26051; Thu, 10 Sep 1998 08:56:16 -0600
Message-Id: <[e-mail]>
From: Steve Hole <[e-mail]>
Date: Thu, 10 Sep 1998 08:55:35 -0600
To: Kazu Yamamoto <[e-mail]>
Subject: Re: Revising RFC 2015
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>   
Sender: [e-mail]
Precedence: bulk

Message-ID: <[e-mail]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a9 Build (12)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9809100855.B; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9809100855.B
Content-Type: Text/PLAIN; CHARSET=US-ASCII


On Wed, 09 Sep 1998 20:28:22 +0900 Kazu Yamamoto <[e-mail]> wrote:

> Also, I proposed not to use multipart/encrypted since it's just
> lengthy(note: the first part is mostly empty). Ned suggested that it's
> nice to align PGP/MIME to the standard way(i.e. multipart security). I
> think this alignment is nice only if ALL encryption mail protocols
> align themselves since these protocol can share reporting mechanism to
> users(e.g. telling users that target objects were automatically
> decrypted). Then S/MIME comes and it doesn't use
> multipart/encrypted. Moreover, MOSS is going to historic. Currently, I
> don't see any reasons why PGP/MIME uses multipart encrypted. It's just
> lengthy.

Being one of the very few people that has implemented both PGP/MIME and S/MIME
into their mail products, I can tell you absolutely that the use of 
Multipart/Encrypted is a MUST.   Especially for IMAP4 mailers where access to
the MIME body structure allows a client to do intelligent things with an
encrypted body part.    You are simply wrong on this count.   I would fight
to the death any attempt to remove multipart/encrypted from the specification.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:[e-mail]  
Phone:[phone]

--Part9809100855.B
Content-Type: Application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version)

iQA/AwUBNffoa9i5Jj9Fn5KMEQJmCQCgvr6YUvGICfw+82EntTlYy9uEhqQAniKM
F5A5C+AxTZMZtBqJ5ls1N7up
=mLrl
-----END PGP SIGNATURE-----

--Part9809100855.B--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18205 for ietf-open-pgp-bks; Thu, 10 Sep 1998 02:26:42 -0700 (PDT)
Received: from slipper.ip.lu (slipper.ip.lu [208.161.252.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18201 for <[e-mail]>; Thu, 10 Sep 1998 02:26:39 -0700 (PDT)
Received: from luxembourg.uucp ([e-mail] [208.161.252.80]) by slipper.ip.lu (8.8.8/8.8.8) with ESMTP id LAA22114; Thu, 10 Sep 1998 11:31:46 +0200 (CEST)
Received: (from roessler@localhost) by  luxembourg.uucp (8.8.8/8.8.8/Debian/GNU) id LAA00828; Thu, 10 Sep 1998 11:29:57 +0200
Date: Thu, 10 Sep 1998 11:29:56 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: the micalg parameter
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.94.3i
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 10, 1998 at 07:10:22AM +0900, Kazu Yamamoto
wrote:

> > There is nothing in the RFC which says an implementation

> Which does this "the RFC" refer to, RFC 1847 or RFC 2015?

2015.  1847 says that certain conditions must be treated
as an error, but this doesn't mean that it has to be
evaluated at all.

> This interpretation is just yours. Since RFC2015 doesn't say accepting
> manner explicitly, there are two possibilities.

> 	(1) mis-match is legal
> 		-> MAY ignore the micalg parameter
> 	(2) mis-match is illegal
> 		-> treat it as garbage? (in your terminology)

Now, why do you think that a mis-match being illegal means
that an implementation can't be robust and ignore the
parameter in this case?  The behaviour is simply undefined, so 
the choice is yours - conform to the GIGO principle or try  
to handle things smoothly.

Actually, I find this situation just fine, so why should
anyone want to change it?

tlr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27312 for ietf-open-pgp-bks; Wed, 9 Sep 1998 16:05:45 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27308 for <[e-mail]>; Wed, 9 Sep 1998 16:05:44 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id IAA19084 for <[e-mail]>; Thu, 10 Sep 1998 08:11:04 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id IAA19677 for <[e-mail]>; Thu, 10 Sep 1998 08:11:03 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id IAA05556 for <[e-mail]>; Thu, 10 Sep 1998 08:11:03 +0900 (JST)
To: [e-mail]
Subject: the micalg parameter
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Wed, 9 Sep 1998 14:34:02 +0200" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 10 Sep 1998 07:10:22 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 44
Sender: [e-mail]
Precedence: bulk

From: Thomas Roessler <[e-mail]>
Subject: Re: Revising RFC 2015
Date: Wed, 9 Sep 1998 14:34:02 +0200

> > I'd suggest that PGP/MIME implementations MUST enumerate
> > correct hash algorithms onto the micalg parameter when
> > generating and PGP/MIME implementations MAY ignore the
> > micalg parameters when accepting.
> 
> There is nothing in the RFC which says an implementation

Which does this "the RFC" refer to, RFC 1847 or RFC 2015?

> MUST evaluate the micalg parameter when accepting, so your
> letter point is precisely what's in the RFC right now.

OK, fine. I wrote my farmer sentence to make my explanation symmetric.
(I didn't claim any RFCs on this topic.)

> That hash algorithms MUST be listed correctly is evident
> from the text and doesn't need to be mentioned separately.

What do you mean "separately"? I didn't say anything about editorical
issues on this topic.

> If a user agent creates a message which doesn't conform to
> the spec, the receiver will conform to the GIGO principle:
> Garbage in, garbage out.  All this is not so new...

OK, this is the point of our debate.

This interpretation is just yours. Since RFC2015 doesn't say accepting
manner explicitly, there are two possibilities.

	(1) mis-match is legal
		-> MAY ignore the micalg parameter
	(2) mis-match is illegal
		-> treat it as garbage? (in your terminology)

Again, PGP/MIME RFC should define both syntax and its semantics. RFC
2015 defines syntax but some semantics are missing.

--Kazu



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27086 for ietf-open-pgp-bks; Wed, 9 Sep 1998 15:48:22 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27082 for <[e-mail]>; Wed, 9 Sep 1998 15:48:21 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id HAA18994 for <[e-mail]>; Thu, 10 Sep 1998 07:53:35 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id HAA19226 for <[e-mail]>; Thu, 10 Sep 1998 07:53:35 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id HAA05108 for <[e-mail]>; Thu, 10 Sep 1998 07:53:35 +0900 (JST)
To: [e-mail]
Subject: the protocol parameter
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Wed, 9 Sep 1998 14:34:02 +0200" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 10 Sep 1998 06:52:53 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 36
Sender: [e-mail]
Precedence: bulk

From: Thomas Roessler <[e-mail]>
Subject: Re: Revising RFC 2015
Date: Wed, 9 Sep 1998 14:34:02 +0200

> > I believe that the protocol parameter is case-insensitive
> > since it refers to content-type which is certainly
> > case-insensitive.
> 
> May I quote from RFC 2045?
> 
>    The type, subtype, and parameter names are not case
>    sensitive.  For example, TEXT, Text, and TeXt are all
>    equivalent top-level media types.  Parameter values are
>    normally case sensitive, but sometimes are interpreted
>    in a case-insensitive fashion, depending on the
>    intended use.  (For example, multipart boundaries are
>    case-sensitive, but the "access-type" parameter for
>    message/External-body is not case-sensitive.)
> 
> So, where precisely is your problem?

I said that RFC 1847 doesn't say the protocol parameter is
case-*in*sensitive.

RFC 2045 says that MIME parameter is case-sensitive unless explicitly
defined so.

According to these two things, readers think that the protocol
parameter is case-sensitive.

However, I think that the protocol parameter is case-*in*sensitive
since content-type is case-*in*sensitive as you quoted.

I'm talking about values of MIME parameter, not parameter name.

--Kazu


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25774 for ietf-open-pgp-bks; Wed, 9 Sep 1998 12:56:17 -0700 (PDT)
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25770 for <[e-mail]>; Wed, 9 Sep 1998 12:56:16 -0700 (PDT)
Received: from xedia.com by relay7.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgdc16595; Wed, 9 Sep 1998 16:01:12 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01264; Wed, 9 Sep 98 15:21:04 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA12434; Wed, 9 Sep 1998 15:21:50 -0400
Date: Wed, 9 Sep 1998 15:21:50 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: New packets in PGP 6.0
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Jack" == Jack Repenning <[e-mail]> writes:

 Jack> At 10:02 AM 9/9/98 , Paul Koning wrote:
 >> No, but strings don't eliminate the registration problem, because
 >> you still need a way to ensure they are unique.  It's just that
 >> the code space is larger which simplifies that task.

 Jack> Strings don't eliminate the _need_ for registration, but they
 Jack> can piggy-back off existing registration systems (such as the
 Jack> DNS system for hostname registration) - which means the
 Jack> availability of strings, plus a convention such as the
 Jack> suggested one for using them, *does* eliminate the registration
 Jack> _problem_.

Yes, any identifying mechanism with hierarchy lets you piggyback off
an existing setup.  This is why a lot of identifiers are built using
the IEEE OUI as a component, and another bunch use OIDs for the same
reason.

DNS hostnames are actually not a good choice.  Unlike OUIs or OIDs,
DNS names are subject to cancellation or revocation if you don't pay
the yearly fee and/or have your chosen name challenged.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25397 for ietf-open-pgp-bks; Wed, 9 Sep 1998 12:15:17 -0700 (PDT)
Received: from parrot.informix.com (ifmxmenlo.informix.com [192.147.112.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA25393 for <[e-mail]>; Wed, 9 Sep 1998 12:15:16 -0700 (PDT)
Received: from repenning by parrot.informix.com (SMI-8.6/SMI-SVR4) id MAA18066; Wed, 9 Sep 1998 12:20:07 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Wed, 09 Sep 1998 12:20:00 -0700
To: [e-mail]
From: Jack Repenning <[e-mail]>
Subject: Re: New packets in PGP 6.0
Cc: Hal Finney <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 11:16 AM 9/9/98 , [e-mail] wrote:

>But is this on by default, or can I expect 99.5% of the PGP key packets I
>get from users and keyservers to have the new packets?

Compatibilty mode for key export is on by default (in the betas I saw, at
any rate).  But it's a persistent check box: the first time a 6.0 user
sends a key to another 6.0 user saying "look at my pretty face," and
eventually figures out why the face wasn't sent, that box will get
unchecked, and that user will start sending troublesome sig-blocks to pre-6
users.  The server-mediated exchange looks rugged to me, but the
user-mediated exchange is going to create confusion.  I dunno about 99.5%;
probably some more-disruptive figure, like 50%....


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25312 for ietf-open-pgp-bks; Wed, 9 Sep 1998 12:09:09 -0700 (PDT)
Received: from parrot.informix.com (ifmxmenlo.informix.com [192.147.112.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA25308 for <[e-mail]>; Wed, 9 Sep 1998 12:09:08 -0700 (PDT)
Received: from repenning by parrot.informix.com (SMI-8.6/SMI-SVR4) id MAA17850; Wed, 9 Sep 1998 12:14:10 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta)
Date: Wed, 09 Sep 1998 12:14:03 -0700
To: Paul Koning <[e-mail]>
From: Jack Repenning <[e-mail]>
Subject: Re: New packets in PGP 6.0
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:02 AM 9/9/98 , Paul Koning wrote:

>No, but strings don't eliminate the registration problem, because you
>still need a way to ensure they are unique.  It's just that the code
>space is larger which simplifies that task.

Strings don't eliminate the _need_ for registration, but they can
piggy-back off existing registration systems (such as the DNS system for
hostname registration) - which means the availability of strings, plus a
convention such as the suggested one for using them, *does* eliminate the
registration _problem_.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24773 for ietf-open-pgp-bks; Wed, 9 Sep 1998 11:11:51 -0700 (PDT)
Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24769 for <[e-mail]>; Wed, 9 Sep 1998 11:11:50 -0700 (PDT)
Received: by brickwall.ceddec.com id <43010>; Wed, 9 Sep 1998 14:15:38 -0400
Date: Wed, 9 Sep 1998 14:16:50 -0400
From: [e-mail]
X-Sender: nobody@mars
To: Hal Finney <[e-mail]>
cc: [e-mail]
Subject: Re: New packets in PGP 6.0
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 9 Sep 1998, Hal Finney wrote:

> One thing more: PGP 6.0 has an option to export key packets in backwards
> compatible format, which will produce OpenPGP compliant messages.  This
> will strip off the Attribute ID packets.  So there is still an OpenPGP
> compliant mode.

But is this on by default, or can I expect 99.5% of the PGP key packets I
get from users and keyservers to have the new packets?





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24728 for ietf-open-pgp-bks; Wed, 9 Sep 1998 11:09:49 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24724 for <[e-mail]>; Wed, 9 Sep 1998 11:09:47 -0700 (PDT)
Received: from whgiii (graywhale16.pcola.gulf.net [205.160.71.207]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id OAA04221; Wed, 9 Sep 1998 14:14:56 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Wed, 09 Sep 1998 13:15:43 -0500
To: Hal Finney <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: New packets in PGP 6.0
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/09/98 
   at 09:58 AM, Hal Finney <[e-mail]> said:

>The new photo id packets are not uploaded to older keyservers by the 6.0
>client.  They are only uploaded to NAI's version 2 LDAP keyservers (which
>is the version which ships with 6.0).  This version of the keyserver
>stores the photoid in a special data structure which will not be
>downloaded pre 6.0 clients.  Only PGP 6.0 knows to ask for data from this
>special data structure where photo ids are kept.

This brings me back to my second question:

Are there any plans for NAI to document the LDAP interface to their
certserver? It would come in handy for those of us developing OpenPGP
applications.

Now I can sift through the 5.5 source code that I have and examine the
packets 6.0 generates while communicating with the certserver but this is
a bit of a PITA.

It would be nice if someone at NAI would write up an informal paper
outlining the communication between the certserver and the client.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: I love running Windows! NOT!

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNfbHh49Co1n+aLhhAQHaTQP+LjvDMaW02J4T1CSiFpkrKpFNEj7XxElm
T7Ao7Nl+DIcDYCQ8OLA1fTpTSie0khqDT8iSiEHIOd8b6VHbmxuZ4nFcds64vAlO
WW8/sBt6DzzD8WeaVyYXxOMo8y+NF3ZcTiXjTbK7havJJlGYW39mccyfWGH8OPs7
WQ6CRsl/nF4=
=BXoh
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23771 for ietf-open-pgp-bks; Wed, 9 Sep 1998 09:57:48 -0700 (PDT)
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23767 for <[e-mail]>; Wed, 9 Sep 1998 09:57:47 -0700 (PDT)
Received: from xedia.com by relay7.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgcq16602; Wed, 9 Sep 1998 13:02:57 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA28359; Wed, 9 Sep 98 13:02:08 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA11907; Wed, 9 Sep 1998 13:02:54 -0400
Date: Wed, 9 Sep 1998 13:02:54 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: New packets in PGP 6.0
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Werner" == Werner Koch <[e-mail]> writes:

 Werner> "William H. Geiger III" <[e-mail]> writes:
 >> So lets say we have packet type 20 -- Generic ID. Then in the type
 >> field:
 >> 
 >> 10 -- PhotoID 15 -- Fingerprint 30 -- Retinal Scan

 Werner> Please do not continue with numeric ids; use strings (like
 Werner> ssh v2) to avoid all these number assignment problems.
 Werner> Numbers can still be assigned but a registration should not
 Werner> be required.  Compared to a size of Photo, the additionl
 Werner> bytes of a string don't count.

No, but strings don't eliminate the registration problem, because you
still need a way to ensure they are unique.  It's just that the code
space is larger which simplifies that task.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23706 for ietf-open-pgp-bks; Wed, 9 Sep 1998 09:54:51 -0700 (PDT)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23702 for <[e-mail]>; Wed, 9 Sep 1998 09:54:50 -0700 (PDT)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.1/8.9.1) with ESMTP id JAA15858; Wed, 9 Sep 1998 09:57:34 -0700 (PDT)
Received: (from hal@localhost) by hal.sb.rain.org (8.7.4/8.7.3) id JAA09686; Wed, 9 Sep 1998 09:58:30 -0700
Date: Wed, 9 Sep 1998 09:58:30 -0700
From: Hal Finney <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: New packets in PGP 6.0
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

William H. Geiger III, <[e-mail]>, writes:
> Well, part of the problem we are going to have here is once these new keys
> get uploaded to to the keyservers. It is my understanding that these new
> packets will break 5.x version of PGP.

Actually PGP 6.0 tries to take some care to avoid breaking existing
software.

The new photo id packets are not uploaded to older keyservers by the
6.0 client.  They are only uploaded to NAI's version 2 LDAP keyservers
(which is the version which ships with 6.0).  This version of the
keyserver stores the photoid in a special data structure which will not
be downloaded pre 6.0 clients.  Only PGP 6.0 knows to ask for data from
this special data structure where photo ids are kept.

When keys are exported explicitly, there is an option in the export
dialog box to cause the photo ids to be stripped, which defaults to the
backwards compatible mode.  The user must go to the advanced preferences
to change this default.

Therefore most users will only be sending their photo ids to the LDAP
keyserver, which will only provide them to 6.0 clients.  It is our
intention that photo ids will remain within the 6.0 "world" as much as
possible.

Hal Finney
Network Associates


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23112 for ietf-open-pgp-bks; Wed, 9 Sep 1998 09:05:22 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23108 for <[e-mail]>; Wed, 9 Sep 1998 09:05:21 -0700 (PDT)
Received: from whgiii (graywhale16.pcola.gulf.net [205.160.71.207]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id MAA02151; Wed, 9 Sep 1998 12:10:03 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Wed, 09 Sep 1998 11:09:49 -0500
To: Hal Finney <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: New packets in PGP 6.0
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/09/98 
   at 08:00 AM, Hal Finney <[e-mail]> said:

>One thing more: PGP 6.0 has an option to export key packets in backwards
>compatible format, which will produce OpenPGP compliant messages.  This
>will strip off the Attribute ID packets.  So there is still an OpenPGP
>compliant mode.

Well, part of the problem we are going to have here is once these new keys
get uploaded to to the keyservers. It is my understanding that these new
packets will break 5.x version of PGP.

One approach would be to strip off these packets before they are accepted
to the keyservers. The other would be to add a PGP Version option to the
keyserver interface and have the server strip any non-compatiable packets
from the keys.

I have already written a utility that will strip the 5.x packets from
2.6.x keys. It would be simple enough to add code to strip the PhotoID
packets.

Are there any plans for NAI to documnet the LDAP interface to their
certserver? It would come in handy for those of us developing OpenPGP
aplications.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Win3.1? For fast relief call 800-3-IBM-OS2.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNfaqQo9Co1n+aLhhAQEqMAP/Yny9xC5o9quw2/hMudBx3b8Rm40VRdOh
5pUPxs0+YsZb4JULosyPSrAAbHlwBvXIjfEataGrlDE3veWLY3ZT0T1TJXyu4ND2
pUfc/yxVhDgOZ3c0uQU9ejYb381Ac456N5t9+y1J9uwzO/GSCLMsi3EHUNObU7MI
dPqvlJJYA3o=
=pUzG
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22880 for ietf-open-pgp-bks; Wed, 9 Sep 1998 08:45:41 -0700 (PDT)
Received: from koeln.shuttle.de ([e-mail] [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22876 for <[e-mail]>; Wed, 9 Sep 1998 08:45:39 -0700 (PDT)
X-Envelope-To: [e-mail]
Received: by koeln.shuttle.de (8.9.1a/8.9.1) id RAA15176 for [e-mail]; Wed, 9 Sep 1998 17:50:42 +0200 (MET DST)
Received: (qmail 544 invoked from network); 9 Sep 1998 15:38:39 -0000
Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Sep 1998 15:38:39 -0000
Received: (qmail 13132 invoked by uid 501); 9 Sep 1998 15:37:51 -0000
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 17:37:51 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: New packets in PGP 6.0
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
X-Mailer: Mutt 0.93i
In-Reply-To: <[e-mail]>; from William H. Geiger III on Wed, Sep 09, 1998 at 08:42:17AM -0500
X-URL: http://www.d.shuttle.de/isil
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

"William H. Geiger III" <[e-mail]> writes:

> So lets say we have packet type 20 -- Generic ID. Then in the type field:
> 
> 10 -- PhotoID
> 15 -- Fingerprint
> 30 -- Retinal Scan

Please do not continue with numeric ids; use strings (like ssh v2) to
avoid all these number assignment problems.  Numbers can still be
assigned but a registration should not be required.  Compared to a
size of Photo, the additionl bytes of a string don't count.

And this does _not_ make the processing more complicated.


Werner



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22409 for ietf-open-pgp-bks; Wed, 9 Sep 1998 07:55:56 -0700 (PDT)
Received: from coyote.rain.org ([e-mail] [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22405 for <[e-mail]>; Wed, 9 Sep 1998 07:55:55 -0700 (PDT)
Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.1/8.9.1) with ESMTP id HAA03970 for <[e-mail]>; Wed, 9 Sep 1998 07:59:55 -0700 (PDT)
Received: (from hal@localhost) by hal.sb.rain.org (8.7.4/8.7.3) id IAA09439 for [e-mail]; Wed, 9 Sep 1998 08:00:32 -0700
Date: Wed, 9 Sep 1998 08:00:32 -0700
From: Hal Finney <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: New packets in PGP 6.0
Sender: [e-mail]
Precedence: bulk

One thing more: PGP 6.0 has an option to export key packets in backwards
compatible format, which will produce OpenPGP compliant messages.  This
will strip off the Attribute ID packets.  So there is still an OpenPGP
compliant mode.

Hal


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21538 for ietf-open-pgp-bks; Wed, 9 Sep 1998 06:29:03 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21532 for <[e-mail]>; Wed, 9 Sep 1998 06:29:02 -0700 (PDT)
Received: from whgiii (rorqual2.pcola.gulf.net [208.22.198.65]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id JAA32706 for <[e-mail]>; Wed, 9 Sep 1998 09:34:15 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Wed, 09 Sep 1998 08:42:17 -0500
To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: Re: New packets in PGP 6.0
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/08/98 
   at 11:35 AM, Jon Callas <[e-mail]> said:

>You are indeed correct that it's a faux pas that it uses 17 for the
>packet id and not something in the 60-63 range. I argued the same thing
>here at NAI, but I lost that debate. I discussed it with John Noerenberg,
>who agreed that it was a faux pas, but not a big one -- especially given
>that the WG consensus was that there should be an implementation first.
>Nonetheless, I agree with you on *that* part of it wholeheartedly. The
>NAI developers are running the risk that OpenPGP 1.1 will define non-text
>user ids to be something incompatible with what they did for PGP 6, and
>they'll have to adapt.

>The PGP developers argued that they should not use the experimental range
>because doing so would de-facto use up that opcode because of all the
>copies of PGP 6 that would use it. I see their point, but I diagree.

Just to make things clear, I do not have a problem with NAI comming up
with something new for PGP, nor do I expect them to come to the WG for
permission to do so. My biggest objection was the grabbing of an
unassigned packet id without telling anyone about it. Now myself and
everyone else have to re-write their code to take these new packets into
account (any keys that I encounter with an unassigned packet id are
assumed to be in error and are rejected). Not major, but a PITA non the
less (FWIW I will be writting a patch for 5.0i when I have some free time
unless someone else feels up to it).

I really think that we need to establish some type of informal mechanism
for assigning numbers (packet, hash, algorithm, ect...) to prevent
problems in the future. I fear that things can get very ugly if we have 4
or 5 different vendors start using unassigned numbers whenever they have
something new to add.

Now as far as PhotoID's and ID's in general. I have mentioned in the past
for having some type of generic ID format that contained a type flag so
applications could invoke some type of sanity checking.

So lets say we have packet type 20 -- Generic ID. Then in the type field:

01 -- RFC822 E-Mail address
02 -- Real Name
03 -- Address
04 -- URL
05 -- X.500
10 -- PhotoID
15 -- Fingerprint
30 -- Retinal Scan

... ect

This seems to be a more sane approach than having a seperate packet type
for each ID format.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Air conditioned environment - Do not open Windows.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNfWG+Y9Co1n+aLhhAQHw9wP/RGr32CxDvsFdiLbpH2I2GMoisoPhTHWa
O8H0GqZbwCW2B7UhvB+YtvINWRP7jstWS1XmzdgInxnU/53XZFRrRkzMKOFZpUMy
0GzS9fhxK3BBAVa4LnFe8Ew8jxa/NCKqe/JNi3hXLBpTIX/hfUt3+T+gZq6SW9CM
124U6jEAzZg=
=C6pq
-----END PGP SIGNATURE-----
 
Tag-O-Matic: To whom the gods destroy, they first teach Windows...



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21524 for ietf-open-pgp-bks; Wed, 9 Sep 1998 06:28:30 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21520 for <[e-mail]>; Wed, 9 Sep 1998 06:28:28 -0700 (PDT)
Received: from whgiii (rorqual2.pcola.gulf.net [208.22.198.65]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id JAA32684; Wed, 9 Sep 1998 09:32:41 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Wed, 09 Sep 1998 08:36:18 -0500
To: Thomas Roessler <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: New packets in PGP 6.0
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/09/98 
   at 02:38 PM, Thomas Roessler <[e-mail]> said:

>On Wed, Sep 09, 1998 at 09:11:44AM +0200, Werner Koch wrote:

>> Suggestion for the future: Include some magic bytes to
>> packets in the experimental range, so you can decide
>> whether it is your experiment or not; same goes for the
>> experimental subkey types.

>Actually, one may wish to formalize a procedure for such
>private extensions.  The secsh (ssh) internet-drafts have
>a nice mechanism for this: They are using textual values
>for about all algorithm IDs, etc.  Experimental or local
>IDs always have the form <local id>@domain, where domain
>is a DNS domain under the control of the entity which
>creates the experimental ID.  For OpenPGP, one could think
>of an "experimental" packet ID which _must_ be followed by
>a string constant containing a local packet ID like the
>one I just described.  The rest of the packet will then
>conform to whatever the extension wants.

I don't know if I really like this as it complicates the packet processing
and is also not compatable with previous versions.

What we could do is make use of the marker packet to id experimental
packets.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: MASOCHIST: Windows SDK programmer with a smile!

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNfaFYY9Co1n+aLhhAQGp6gP9FtUElN/u/C11xvGggYy2r0wwsMDtkTKL
NLD1Q1qzYXHTdpJbhLBpOoP0ONN+RaHkBQlKPO4Ay6RZUe8lyBr4DFdbQTfu7wlU
EeOR3SpeLcexVr3s4+4F9y7DfCyubp8vlYcE/b1arOzUIcY48pcYXh4uU1ekxJr/
vyjKcoDNogE=
=+5it
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21120 for ietf-open-pgp-bks; Wed, 9 Sep 1998 05:36:51 -0700 (PDT)
Received: from work1.rhrz.uni-bonn.de (work1.rhrz.uni-bonn.de [131.220.16.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21116 for <[e-mail]>; Wed, 9 Sep 1998 05:36:47 -0700 (PDT)
Received: from sobolev.rhein.de ([e-mail] [131.220.244.220]) by work1.rhrz.uni-bonn.de (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id OAA24236 for <[e-mail]>; Wed, 9 Sep 1998 14:41:49 +0200
Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU) id OAA31105 ; Wed, 9 Sep 1998 14:38:36 +0200
Date: Wed, 9 Sep 1998 14:38:35 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: New packets in PGP 6.0
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.94.5i
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 09, 1998 at 09:11:44AM +0200, Werner Koch wrote:

> Suggestion for the future: Include some magic bytes to
> packets in the experimental range, so you can decide
> whether it is your experiment or not; same goes for the
> experimental subkey types.

Actually, one may wish to formalize a procedure for such
private extensions.  The secsh (ssh) internet-drafts have
a nice mechanism for this: They are using textual values
for about all algorithm IDs, etc.  Experimental or local
IDs always have the form <local id>@domain, where domain
is a DNS domain under the control of the entity which
creates the experimental ID.  For OpenPGP, one could think
of an "experimental" packet ID which _must_ be followed by
a string constant containing a local packet ID like the
one I just described.  The rest of the packet will then
conform to whatever the extension wants.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21108 for ietf-open-pgp-bks; Wed, 9 Sep 1998 05:34:53 -0700 (PDT)
Received: from work1.rhrz.uni-bonn.de (work1.rhrz.uni-bonn.de [131.220.16.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21104 for <[e-mail]>; Wed, 9 Sep 1998 05:34:46 -0700 (PDT)
Received: from sobolev.rhein.de ([e-mail] [131.220.244.220]) by work1.rhrz.uni-bonn.de (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id OAA33178 for <[e-mail]>; Wed, 9 Sep 1998 14:39:44 +0200
Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU) id OAA30924 ; Wed, 9 Sep 1998 14:34:02 +0200
Date: Wed, 9 Sep 1998 14:34:02 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: Revising RFC 2015
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.94.5i
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 09, 1998 at 08:28:22PM +0900, Kazu Yamamoto
wrote:

> >   Clearly, this is a layer 1 incompatibility.

> Uhhhm. From the PGP/MIME implementors of view, I like to
> have semantics of this case. What kinds of action does
> PGP/MIME take?

As we are talking about layer 1 incompatiblities, OpenPGP
defines some behaviour for the PGP engine.  This behaviour
is passed to the PGP/MIME MUA.  So there is absolutely no
need to specify anything about such incompatibilities in a
PGP/MIME text.

>> - Alice encrypts a message with Bob's public key and
>>   sends it to Bob.  Now, this is an issue already dealt
>>   with in the OpenPGP draft, so it's out of the scope of
>>   PGP/MIME.

>> - Alice sends a public key to Bob, but Bob's PGP version
>>   is not able to handle this kind of public key.  Well,
>>   that's tough luck, so they won't be able to communicate
>>   securely.

> Ah-ha! Your point is that a sender can guess receiver's
> PGP version thanks to his public key.

> But with PGP 5.x spec, it is possible to encrypt a
> message with Triple DES, which can be not handled by PGP
> 2.x, whose session key is encrypted by RSA. I think that
> the story is not so simple.

I have to repeat myself: This is an issue which is dealt
with in the OpenPGP draft, so it's out of the scope of
PGP/MIME.

> I'd suggest that PGP/MIME implementations MUST enumerate
> correct hash algorithms onto the micalg parameter when
> generating and PGP/MIME implementations MAY ignore the
> micalg parameters when accepting.

There is nothing in the RFC which says an implementation
MUST evaluate the micalg parameter when accepting, so your
letter point is precisely what's in the RFC right now.

That hash algorithms MUST be listed correctly is evident
from the text and doesn't need to be mentioned separately.

If a user agent creates a message which doesn't conform to
the spec, the receiver will conform to the GIGO principle:
Garbage in, garbage out.  All this is not so new...

> Please remember my conceptual model. PGP/MIME UA must
> tell what kind of symmetric crypto (and more) to PGP
> engine. (2.1)

That's an issue _every_ PGP front-end has to deal with. It
isn't MIME-specific at all.  Additionally, the OpenPGP
spec does already deal with this issue.  May I point you
to section 5.2.3.6 of the draft?

> (2.3) is semantic issue of PGP/MIME.

Sorry, no.  This is a semantic issue of _any_ OpenPGP
implementation, at any layer, and it's not at all specific
to PGP/MIME.  (2.3 was the question what kind of action a
MUA should take if it receives unrecognized PGP packets.)

>> 2.4 and 2.5 are yet another category: Here, you are
>> dealing with general MIME handling.  Now, this is an
>> issue to be handled in the "generic" MIME documents, but
>> once again not in a PGP/MIME text.  For the purpose of
>> PGP/MIME, we can simply assume that a MUA should behave
>> according to the generic texts.

(2.4 and 2.5 were the question what kinds of MIME
content-types am MUA must be able to handle and generate
in order to conform to the spec.)

> Maybe. Nonetheless, implementation note of this kind is
> useful to let implementators program correctly.

Pardon me?  The content-types supported by a MUA have
absolutely nothing to do with PGP/MIME; they have
everything to do with MIME.  Essentially, this is a
decision you have to make as a MUA author.  Your
"customers" will tell you if your program is usable or
not.

>>> MIME clearly defines any MIME parameters are
>>> case-*sensitive* if it is not defined so. And RFC 1847
>>> doesn't say the protocol parameter is case-insensitive.

>> So it's case-sensitive in PGP/MIME as well, that's what
>> I've said.  Where's the problem with that?

> I believe that the protocol parameter is case-insensitive
> since it refers to content-type which is certainly
> case-insensitive.

May I quote from RFC 2045?

   The type, subtype, and parameter names are not case
   sensitive.  For example, TEXT, Text, and TeXt are all
   equivalent top-level media types.  Parameter values are
   normally case sensitive, but sometimes are interpreted
   in a case-insensitive fashion, depending on the
   intended use.  (For example, multipart boundaries are
   case-sensitive, but the "access-type" parameter for
   message/External-body is not case-sensitive.)

So, where precisely is your problem?

tlr   
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20855 for ietf-open-pgp-bks; Wed, 9 Sep 1998 04:30:00 -0700 (PDT)
Received: from hikari.iij.ad.jp (h013.p107.iij4u.or.jp [210.130.107.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20848 for <[e-mail]>; Wed, 9 Sep 1998 04:29:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hikari.iij.ad.jp (8.8.8/8.8.8) with ESMTP id UAA00639; Wed, 9 Sep 1998 20:28:23 +0900 (JST) (envelope-from [e-mail])
To: [e-mail]
Cc: [e-mail]
Subject: Re: Revising RFC 2015
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Fri, 4 Sep 1998 14:38:25 +0200" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 09 Sep 1998 20:28:22 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 202
Sender: [e-mail]
Precedence: bulk

Thomas, 

Sorry for my late response. I was busy for the last few day.

From: Thomas Roessler <[e-mail]>
Subject: Re: Revising RFC 2015
Date: Fri, 4 Sep 1998 14:38:25 +0200

> Let me elaborate my point in a different manner.  We have
> several layers between which we should distinguish:

[deleted]

> Layers 1-3 (including ascii armor for signatures) are
> specified in the OpenPGP draft and should be handled as
> mostly opaque by a PGP/MIME text (they are by RFC 2015).
> If there are problems on these layers, they should be
> dealt with in the next generation OpenPGP RFC.

This layer model seems good.

But I have another *conceptual* model. (Probably we are explaining the
same thing with different terminology.) In my model, there are two
entities: PGP/MIME MUA and PGP engine. The PGP/MIME MUA drives the PGP
engine.

So, PGP/MIME should
	(1) define PGP/MIME formant
and
	(2) provide necessary information for MUAs to drive PGP engines.

> Layers three and four are pretty much the interface
> between MUA and PGP application.  Essentially, one of the
> two mappings applied is usually the identity, while the
> other one is more or less base64.

This is perhaps the same of my conceptual model.

> - Alice signs a message with a key and/or signature format
>   which is not understood by Bob's software.  In this
>   case, Bob's software will kindly bail out and tell him
>   that the signature can't be verifyed for this and that
>   reason.  Nevertheless, Bob's MUA will be able to display
>   the text of the message since the message is present in
>   MIME clear-text.

Right.

>   Clearly, this is a layer 1 incompatibility.

Uhhhm. From the PGP/MIME implementors of view, I like to have
semantics of this case. What kinds of action does PGP/MIME take?

> - Alice encrypts a message with Bob's public key and sends
>   it to Bob.  Now, this is an issue already dealt with in
>   the OpenPGP draft, so it's out of the scope of PGP/MIME.
> - Alice sends a public key to Bob, but Bob's PGP version
>   is not able to handle this kind of public key.  Well,
>   that's tough luck, so they won't be able to communicate
>   securely.

Ah-ha! Your point is that a sender can guess receiver's PGP version
thanks to his public key.

But with PGP 5.x spec, it is possible to encrypt a message with Triple
DES, which can be not handled by PGP 2.x, whose session key is
encrypted by RSA. I think that the story is not so simple.

> All this means that there are no version control issues to
> be dealt with on the MIME layer, so I think we should
> leave them out.

Sorry, I disagree. Please see below.

> OK, fine with me.  Can I state the consensus that we leave
> everything as it is now and simply add the new hash
> algorithms?

I agree. But please define semantics for mismatch between 
the micalg parameter and parameters inside PGP packets. 

I'd suggest that PGP/MIME implementations MUST enumerate correct hash
algorithms onto the micalg parameter when generating and PGP/MIME
implementations MAY ignore the micalg parameters when accepting.

> >>> (2.1) What kinds of algorithm (for symmetric crypt,
> >>> asymmetric crypt, hash) is preferred when generated?
> >>> (2.3) What kind of actions should be taken if MUA
> >>> receives unrecognized PGP packets?
> >>> (2.4) Generating: what kind of content-type must MUA be
> >>> able to generate? If MUA can sign only text/plain, is it
> >>> conformable?
> >>> (2.5) Accepting: what kind of content-type must MUA be
> >>> able to handle? If MUA can't verify signed text/plain
> >>> under multipart/mixed, is it conformable?
> > This is not a format issue but a standardization issue.
> > Thus certainly protocol issue. Recently, many other
> > protocols define minimum conformant set for generating
> > and accepting.
> Let's revisit these points, and let's think layers while
> doing so.
> 
> 2.1, 2.2 and 2.3 are clearly issues on layers one and two,
> so I'd consider them to be outside the scope of the
> PGP/MIME spec.

No. Please remember my conceptual model. PGP/MIME UA must tell what
kind of symmetric crypto (and more) to PGP engine. (2.1)

(2.3) is semantic issue of PGP/MIME.

> 2.4 and 2.5 are yet another category: Here, you are
> dealing with general MIME handling.  Now, this is an issue
> to be handled in the "generic" MIME documents, but once
> again not in a PGP/MIME text.  For the purpose of
> PGP/MIME, we can simply assume that a MUA should behave
> according to the generic texts.

Maybe. Nonetheless, implementation note of this kind is useful to let
implementators program correctly.

> So if we want to drop ASCII armor on the long run, we
> should do so _everywhere_.

I agree. 

I don't know you know the old discussions on PGP/MIME when RFC2015 was
IDs. Actually, I proposed to use MIME encoding instead of ASCII armor
at that time. This proposal was rejected but I couldn't see any
technical reasons why rejected.

To my experiences, ASCII armor is less friendly to non-PGP/MIME UAs
than it seems to be. PGP/MIME signed objects can't be verify by the
PGP program(note: PGP 5.0 can do this if compiled with the MIMEPARSE
macro). So, the second part, detached signature, is not necessary to
be encoded with ASCII armor.

For PGP/MIME encrypted object, RFC2015 is not friendly to the PGP
program, neither. Yes, the object can be decrypted by PGP but it is
not so easy to remove MIME header preceding the target object. Please
imagine that you remove CT: preceding a GIF image file by your editor.
All in all, manual processing is necessary and MIME encoding programs
are out there. So, I don't see any technical reasons for ASCII armor.

Also, I proposed not to use multipart/encrypted since it's just
lengthy(note: the first part is mostly empty). Ned suggested that it's
nice to align PGP/MIME to the standard way(i.e. multipart security). I
think this alignment is nice only if ALL encryption mail protocols
align themselves since these protocol can share reporting mechanism to
users(e.g. telling users that target objects were automatically
decrypted). Then S/MIME comes and it doesn't use
multipart/encrypted. Moreover, MOSS is going to historic. Currently, I
don't see any reasons why PGP/MIME uses multipart encrypted. It's just
lengthy.

Anyway, past is past. This is just for your information.

> A suggestion on this topic:
> 
> - Implementations MUST be able to accept ASCII armor
>   representations of PGP objects.  They SHOULD be able to
>   accept the binary representation.

I like to change the last SHOULD to MUST because accepting syntax is
like that.

> >>> (4.1) Why not text/pgp?
> 
> >>> (4.2) S/MIME doesn't use multipart/encrypted. Why does
> >>> PGP/MIME?

> > No. RFC is the best place to answer any technical
> > questions. 
> 
> Correct.  But RFCs are _not_ the best place to extensively
> discuss the rationale behind certain basic decisions.
> Specifically, an RFC which is merely a revised version of
> an existing one should not start to explain the design
> decisions behind that existing RFC.  (IMHO)

OK, let me enumerate an example with my IPsec hat.

The IPsec architecture draft explains why two protocols, namely AH and
ESP, are provided.

Also, RFC2015 starts with objections to the application/pgp approach.

# I don't like this relative prologue. I think that PGP/MIME RFC
# should start with "why PGP/MIME". Comparison with other approaches
# should go to a later session.

> > MIME clearly defines any MIME parameters are
> > case-*sensitive* if it is not defined so. And RFC 1847
> > doesn't say the protocol parameter is case-insensitive.
> 
> So it's case-sensitive in PGP/MIME as well, that's what
> I've said.  Where's the problem with that?

I believe that the protocol parameter is case-insensitive since it
refers to content-type which is certainly case-insensitive. 

--Kazu


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA12304 for ietf-open-pgp-bks; Wed, 9 Sep 1998 00:09:27 -0700 (PDT)
Received: from koeln.shuttle.de ([e-mail] [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA12295 for <[e-mail]>; Wed, 9 Sep 1998 00:09:17 -0700 (PDT)
X-Envelope-To: [e-mail]
Received: by koeln.shuttle.de (8.9.1a/8.9.1) id JAA07794 for [e-mail]; Wed, 9 Sep 1998 09:14:10 +0200 (MET DST)
Received: (qmail 21321 invoked from network); 9 Sep 1998 07:12:50 -0000
Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Sep 1998 07:12:50 -0000
Received: (qmail 11484 invoked by uid 501); 9 Sep 1998 07:11:45 -0000
Message-ID: <[e-mail]>
Date: Wed, 9 Sep 1998 09:11:44 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: New packets in PGP 6.0
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
X-Mailer: Mutt 0.93i
In-Reply-To: <[e-mail]>; from Jon Callas on Tue, Sep 08, 1998 at 11:35:11AM -0700
X-URL: http://www.d.shuttle.de/isil
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Jon Callas <[e-mail]> writes:

> The PGP developers argued that they should not use the experimental range
> because doing so would de-facto use up that opcode because of all the
> copies of PGP 6 that would use it. I see their point, but I diagree.

Suggestion for the future:  Include some magic bytes to packets in the
experimental range, so you can decide whether it is your experiment or
not; same goes for the experimental subkey types.


Werner 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24969 for ietf-open-pgp-bks; Tue, 8 Sep 1998 11:34:03 -0700 (PDT)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24965 for <[e-mail]>; Tue, 8 Sep 1998 11:34:02 -0700 (PDT)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id LAA01867; Tue, 8 Sep 1998 11:38:19 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 08 Sep 1998 11:35:11 -0700
To: "William H. Geiger III" <[e-mail]>, "William Allen Simpson" <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: New packets in PGP 6.0
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

A number of things:

To Bill Geiger:

Bill, this isn't the first anyone's heard of the picture ID packets. I made
a proposal that we discuss them in draft -00. I distinctly remember
discussing the issue with you in Washington, and told you that they were on
our schedule for 6.0. Phil made a couple of pleas for them, and Hal
submitted a definition suggestion to the list. It was met with a resounding
thud. William Simpson argued forcefully against them for 1.0, and since the
only people who really seemed to be *for* them were NAI people, I let the
issue drop. Ironically, the reason for *not* putting them in V1.0 was that
no one has implemented them, so they should get field experience before
going in the standard.

I admit that I did not raise a huge stink over the issue, but if you
weren't aware of it, then you weren't reading your mail. I've worked hard
to balance being the spec editor along with working on PGP. I let that
issue drop because I felt that pursuing it any further would be ramrodding
a feature into the spec just because we implemented it, especially with the
WG saying there should be implementation experience *before* the feature
went in the spec. I did keep the WG chair informed of the entire situation,
though. 

You are indeed correct that it's a faux pas that it uses 17 for the packet
id and not something in the 60-63 range. I argued the same thing here at
NAI, but I lost that debate. I discussed it with John Noerenberg, who
agreed that it was a faux pas, but not a big one -- especially given that
the WG consensus was that there should be an implementation first.
Nonetheless, I agree with you on *that* part of it wholeheartedly. The NAI
developers are running the risk that OpenPGP 1.1 will define non-text user
ids to be something incompatible with what they did for PGP 6, and they'll
have to adapt.

The PGP developers argued that they should not use the experimental range
because doing so would de-facto use up that opcode because of all the
copies of PGP 6 that would use it. I see their point, but I diagree.

To William Simpson:

It has *not* been over a year for the spec. The OpenPGP BOF was in Munich,
Aug '97. The approval from the IESG came on Sept 18. Yes, it took me nearly
two months to get the -00 draft out, but I disagree completely that the
whole process could have been done in substantially shorter time. The two
major complaints I've gotten about the pace have been that we're taking too
long and that we're moving too fast. Even at the langorous pace we've
taken, we've only gotten where we are by aggressively deferring issues.
Getting complaints about pace from both directions is to me a pretty good
indicator that we're somewhere in the "fast enough" range even if it's at
the slow end of that range.

	Jon



-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24723 for ietf-open-pgp-bks; Tue, 8 Sep 1998 11:12:00 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24719 for <[e-mail]>; Tue, 8 Sep 1998 11:11:59 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA11919; Tue, 8 Sep 1998 14:16:39 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: OpenPGP Message Format to Proposed Standard
Reply-to: [e-mail]
Date: Tue, 08 Sep 1998 14:16:39 -0400
Sender: [e-mail]
Precedence: bulk

The IESG has received a request from the Open Specification for Pretty
Good Privacy Working Group to consider OpenPGP Message Format
<draft-ietf-openpgp-formats-07.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by September 22, 1998.

Files can be obtained via
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-07.txt



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06617 for ietf-open-pgp-bks; Mon, 7 Sep 1998 09:21:06 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06612 for <[e-mail]>; Mon, 7 Sep 1998 09:21:04 -0700 (PDT)
Received: from whgiii (graywhale42.pcola.gulf.net [205.160.71.233]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id MAA28534; Mon, 7 Sep 1998 12:25:46 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Mon, 07 Sep 1998 11:22:30 -0500
To: "William Allen Simpson" <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: New packets in PGP 6.0
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

In <[e-mail]>, on 09/07/98 
   at 12:56 PM, "William Allen Simpson" <[e-mail]> said:

>As I have to keep reminding folks every few months, the charter of this
>WG was to update the old RFC-1991, document the actual design of PGP 5.0,
>make some choices about what we were going to keep (IETF assumes change
>control), and specifically was supposed to avoid disenfranchising earlier
>PGP users.

>The second deliverable, which as I remember was a PKI, we dropped from
>the Charter.

>This was not supposed to include 5.5, and certainly not 6.0.

>Unfortunately, Callas turned out to be incredibly slow at writing
>documentation.  A typical programmer problem.  So, what should have taken
>at most 3-4 months, took over a year.

>Meanwhile, they've come out with new versions.  Can you blame them? Silly
>folks are trying to make enough to keep eating....

William,

I would have taken someone at NAI a whole 5 mins to drop a note to the
list saying "by the way we would like to reserver packet types 16-20 for
some stuff we are playing with". Or even better they could have used the
private/experimental range of packet numbers 60-63.

I don't know about you, but I do not like the idea off all unassigned
numbers in the RFC being reserved for NAI use.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Taking the wind out of Windows.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNfQK7o9Co1n+aLhhAQFpowP/Ud9gipUmYCN9ffuJGHGOjwhEVW9SVHTP
mKUIyEGhjnLDvNMQNocGunwLroxHjoU19SZ0WtUGIU70y7oGcAPf+l2145TInv9w
/yXS6CMYMqYC4FcuQnTTuk6sRJS6f6ZNJxwWJ8rKSXwfqClcNo3hDS+sx5Iwtfjd
pwfPMhjIMS4=
=4Z58
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05439 for ietf-open-pgp-bks; Mon, 7 Sep 1998 06:24:52 -0700 (PDT)
Received: from merit.edu (merit.edu [198.108.1.42]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05435 for <[e-mail]>; Mon, 7 Sep 1998 06:24:51 -0700 (PDT)
Received: from pm454-19.dialip.mich.net (pm454-19.dialip.mich.net [198.110.20.221]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA24401 for <[e-mail]>; Mon, 7 Sep 1998 09:29:57 -0400 (EDT)
Date: Mon, 7 Sep 98 12:56:00 GMT
From: "William Allen Simpson" <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Re: New packets in PGP 6.0
Sender: [e-mail]
Precedence: bulk

As I have to keep reminding folks every few months, the charter of this
WG was to update the old RFC-1991, document the actual design of PGP
5.0, make some choices about what we were going to keep (IETF assumes
change control), and specifically was supposed to avoid disenfranchising
earlier PGP users.

The second deliverable, which as I remember was a PKI, we dropped from
the Charter.

This was not supposed to include 5.5, and certainly not 6.0.

Unfortunately, Callas turned out to be incredibly slow at writing
documentation.  A typical programmer problem.  So, what should have
taken at most 3-4 months, took over a year.

Meanwhile, they've come out with new versions.  Can you blame them?
Silly folks are trying to make enough to keep eating....


> From: "William H. Geiger III" <[e-mail]>
> What exactly is the point of having a RFC if the PGP guys at NAI are not
> going to follow it? I had made the assumption that the PhotoID was being
> added as a subpacket to the self-signature, as this would be supported by
> the I-D and seemed like a logical place to put it.
>
But we don't have to follow them.  Let's put the packet in the right
place in a "modifications" RFC.  I'm sure they will come out with a 6.1
to follow the IETF. :-)


> Note to the NAI people on the list:
>
> You guys have know about this PhotoID for some time now. Why is it that we
> are only hearing about this now? And even more germane, why are we hearing
> about it from someone other than one of you?
>
> If every time NAI makes a new release we have to hack through the code and
> the output, what is the point of having an RFC at all?? It does not bode
> well for a standard when the principle vendor breaks it with their 1st
> release.
>

[e-mail]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA01820 for ietf-open-pgp-bks; Mon, 7 Sep 1998 01:02:28 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA01811; Mon, 7 Sep 1998 01:02:26 -0700 (PDT)
Received: from whgiii (minke21.pcola.gulf.net [205.160.71.36]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id EAA21839; Mon, 7 Sep 1998 04:07:29 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Mon, 07 Sep 1998 03:14:33 -0500
To: [e-mail], [e-mail]
Subject: OT: KRAP is at it in the IETF
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

Sorry for the off-topic post but it seemd of interest to members of the
list. Please follow up off list.

Thanks,

-----BEGIN PGP SIGNED MESSAGE-----

Hello,

It has come to my attention that the KRAP (key recovery alliance program)
has submitted an I-D (internet draft) to the IETF for adding GAK
(government access to keys) to the IPSEC protocols:

ftp://ftp.ietf.org/internet-drafts/draft-rfced-exp-markham-00.txt

ISAKMP Key Recovery Extensions
<draft-rfced-exp-markham-00.txt>

7. AUTHOR INFORMATION

   Tom Markham
   Secure Computing Corp
   2675 Long Lake Road
   Roseville, MN 55113   USA

   Phone: [phone],    Fax:   [phone]
   EMail: [e-mail]


I consider this a perversion of the standards process of the IETF to
advance a political agenda which must be stopped at all cost.

Below are the e-mail addresses of some people that you should write
(politely) expressing your objections to any such additions to the
protocols:

IPSEC Chairs:

Theodore Ts'o <[e-mail]>
Robert Moskowitz <[e-mail]>

Security Area Directors:

Jeffrey Schiller <[e-mail]>
Marcus Leech <[e-mail]>

As I mentioned before, be polite. These people are not the ones proposing
GAK be added to the IPSEC protocols. They have put a lot of time and
effort in forwarding the cause for strong encryption. They should be made
aware of the communities objections to these attempts by KRAP.

Thanks,

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: It's OS/2, Jim, but not OS/2 as we know it.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNfOVk49Co1n+aLhhAQFJwwP+O4vrZVKFpOG8vCHFwbDuPIv/99AhBnKF
RK/Ikc5y2gGKq9hfxkTb4o77YUrDaEGkYUPHk+ZC57Oag0Lu1v6W1EAbQ5T4RpzH
JWYXOonQmbqw5rH0h6brzqrH3ep9Ej9DR0gv4mGgIfSNlJSUu6TWO5ZHXKWiE4yy
5flH0Ngg/TI=
=EzNL
-----END PGP SIGNATURE-----
 
Tag-O-Matic: Win3.1? For fast relief call 800-3-IBM-OS2.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA24995 for ietf-open-pgp-bks; Sun, 6 Sep 1998 02:21:56 -0700 (PDT)
Received: from work1.rhrz.uni-bonn.de (work1.rhrz.uni-bonn.de [131.220.16.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA24991 for <[e-mail]>; Sun, 6 Sep 1998 02:21:54 -0700 (PDT)
Received: from sobolev.rhein.de ([e-mail] [131.220.244.33]) by work1.rhrz.uni-bonn.de (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id LAA44424 for <[e-mail]>; Sun, 6 Sep 1998 11:26:45 +0200
Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU) id LAA23200 ; Sun, 6 Sep 1998 11:23:58 +0200
Date: Sun, 6 Sep 1998 11:23:58 +0200
From: Thomas Roessler <[e-mail]>
To: IETF OpenPGP <[e-mail]>
Subject: Re: Revising RFC 2015
Message-ID: <[e-mail]>
Mail-Followup-To: IETF OpenPGP <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.94.4i
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

On Sat, Sep 05, 1998 at 11:25:13AM +0000, Lindsay
Mathieson wrote:

> 1.	Every existing MIME implementation has base64
> encoding code (which is exactly the same as ASCII armour,
> minus the CRC

correct.

> 2.	The MIME spec ban's nested encodings of MIME
> objects

Correct, but irrelevant.

When signing messages and sending keys according to the
PGP/MIME RFC, no nested encoding of MIME objects occurs.
And, additionally, the "no nested encodings" stuff simply
doesn't apply if we are talking about _encrypting_ MIME
objects.

> 3.	Every PGP implementation to date may have ASCII
> Armour, but they should also have a binary output option
> - certainly PGP itself does. This works well with RFC
> 1847 & 2015 as the PGP binary object can be attached and
> encoded with base64.

Pardon me?  RFC 2015 mandates ASCII armor, not MIME
encoding for PGP encrypted objects.

> 4.	Using ASCII Armour would break most MIME
> implementations and *really* annoy the MIME team.

Is it remotely possible that you don't really understand
what this discussion is about?  ASCII armor is _only_
relevant for PGP objects which are fed into some PGP
backend unchanged.  These objects are handled as opaque by
MUAs, so using ASCII armor here just means that MUAs don't
need to care about MIME decoding at this point.

Additionally, it means that these folks who use non-MIME
MUAs may be able to process the PGP objects "manually"
(editor + pgp).

To make a long story short: Try reading RFC 2015.  Try
reading some code which implements it.  Try processing
messages which conform to 2015 with non-PGP enabled MIME
MUAs.  Try processing them manually.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA23054 for ietf-open-pgp-bks; Sat, 5 Sep 1998 17:18:16 -0700 (PDT)
Received: from enterprise.powerup.com.au ([e-mail] [203.32.8.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA23050 for <[e-mail]>; Sat, 5 Sep 1998 17:18:15 -0700 (PDT)
Message-Id: <[e-mail]>
Received: (qmail 17680 invoked from network); 6 Sep 1998 00:22:55 -0000
Received: from ts5135.powerup.com.au (HELO lindsay) (202.139.237.35) by enterprise.powerup.com.au with SMTP; 6 Sep 1998 00:22:55 -0000
Date: 5 Sep 1998 11:25:13 GMT
From: Lindsay Mathieson <[e-mail]>
Subject: Re: Revising RFC 2015
To: "William H. Geiger III" <[e-mail]>, IETF OpenPGP <[e-mail]>
X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.8 Preview 2
Sender: [e-mail]
Precedence: bulk

>We are not bringing up this old ghost are we? Every PGP implementation
>to date uses ASCII-Armor, it is there and everyone has the code for it.
>Using anything other than Ascii-Armor for 8bit to 7bit conversion of
>PGP packets only complicates the issue.

This is no old ghost, and needs to be settled. I am absolutley opposed to
using ASCII armour with MIME.

1.	Every existing MIME implementation has base64 encoding code (which is
exactly the same as ASCII armour, minus the CRC

2.	The MIME spec ban's nested encodings of MIME objects

3.	Every PGP implementation to date may have ASCII Armour, but they should
also have a binary output option - certainly PGP itself does. This works
well with RFC 1847 & 2015 as the PGP binary object can be attached and
encoded with base64.

4.	Using ASCII Armour would break most MIME implementations and *really*
annoy the MIME team.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.8 Preview 2, on September 5, 1998, in
Win95 4.0
	http://www.blackpaw.com/





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22767 for ietf-open-pgp-bks; Sat, 5 Sep 1998 15:32:08 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA22763 for <[e-mail]>; Sat, 5 Sep 1998 15:32:05 -0700 (PDT)
Received: from whgiii (minke5.pcola.gulf.net [205.160.71.20]) by domains.invweb.net (8.9.1/8.9.1) with SMTP id SAA27896; Sat, 5 Sep 1998 18:36:42 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Sat, 05 Sep 1998 17:44:34 -0500
To: [e-mail]
In-Reply-To: <[e-mail]>
Cc: [e-mail]
Subject: Re: New packets in PGP 6.0
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

In <[e-mail]>, on 09/05/98 
   at 11:19 PM, Patrick Feisthammel <[e-mail]> said:

>Hi!

>The PGP 6.0 seems to introduce new packet types. 

>The photo pictures are in a package with the tag 17.
>The signature binding the photo to the key seems to be a normal sig of 
>type 0x10 (Generic certification of a UserID and Public Key Packet).

>Some questions arise:

>1. Is it save to ignore any unknown packet? 
>If yes, perhaps it shoul be added to the -08 spec after the list of
>packet tags in the chapter "Packet Tags".

>2. What format do the x.509 keys have in PGP 6.0 keyrings?
>(Does someone have a sample?) 

>3. Will Open PGP support x.509 keys? I found some discussing on the list
>but no final decision.

>4. For the keyserver folks: PGP 6.0 seams to strip the image packets, if
>the keyserver is not a Certificate Server 2.0...

I find this quite troubling.

What exactly is the point of having a RFC if the PGP guys at NAI are not
going to follow it? I had made the assumption that the PhotoID was being
added as a subpacket to the self-signature, as this would be supported by
the I-D and seemed like a logical place to put it.

Note to the NAI people on the list:

You guys have know about this PhotoID for some time now. Why is it that we
are only hearing about this now? And even more germane, why are we hearing
about it from someone other than one of you?

If every time NAI makes a new release we have to hack through the code and
the output, what is the point of having an RFC at all?? It does not bode
well for a standard when the principle vendor breaks it with their 1st
release.

I am not happy with this at all.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22527 for ietf-open-pgp-bks; Sat, 5 Sep 1998 14:15:00 -0700 (PDT)
Received: from dns.h.rubin.ch (dial-pri-na002.active.ch [193.135.163.171]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22520 for <[e-mail]>; Sat, 5 Sep 1998 14:14:57 -0700 (PDT)
Received: from localhost (listen@localhost) by dns.h.rubin.ch (8.8.8/8.8.8) with SMTP id XAA22812 for <[e-mail]>; Sat, 5 Sep 1998 23:19:30 +0200
Date: Sat, 5 Sep 1998 23:19:20 +0200 (CEST)
From: Patrick Feisthammel <[e-mail]>
X-Sender: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: New packets in PGP 6.0
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Hi!

The PGP 6.0 seems to introduce new packet types. 

The photo pictures are in a package with the tag 17.
The signature binding the photo to the key seems to be a normal sig of 
type 0x10 (Generic certification of a UserID and Public Key Packet).

Some questions arise:

1. Is it save to ignore any unknown packet? 
If yes, perhaps it shoul be added to the -08 spec after the list of packet
tags in the chapter "Packet Tags".

2. What format do the x.509 keys have in PGP 6.0 keyrings?
(Does someone have a sample?) 

3. Will Open PGP support x.509 keys? I found some discussing on the list
but no final decision.

4. For the keyserver folks: PGP 6.0 seams to strip the image packets, if
the keyserver is not a Certificate Server 2.0...

Cheers,
Patrick

- ---
PGP-KeyID: DD934139 ([e-mail])    encrypt mail with PGP if possible
more about PGP on http://www.rubin.ch/pgp/ (english and german)
what ist the web of trust? see http://www.rubin.ch/pgp/weboftrust.en.html
Das Vertrauensnetz von PGP:    http://www.rubin.ch/pgp/weboftrust.de.html


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQESAwUBNfGq35VgYabdk0E5AQHYHwfiA57BgkufCaeq6Ojgvz7raOmo2Hsmqvjn
eeZoeNmQAmdHAwRazKT0W4r3+ROSWVnFiSpLWvf+T/MaX1r6qSiLEIMDH81xIARQ
Gv1OsacjCMDzFZ2LwaWDIN2JAyKbeFBI0Bu1XsYAeryUtF3D775KAb9LvMnXCFf5
/kU7W+IB4QYWL23LwAy3TABRLZSOcBGdo5fWiTDQIp2uncZYSDdrF+CI8zNZlS0F
sWQ1E/lwnQEhNqJFK6XAVTrIauTkzS8K4amQw+NMv2+ImBgkZkqC6kj0zAebHTti
2MerFF9tHzX4K6NXVCZPzH8t6qU6jM5B6jVvFyYLiaIpijlqMA==
=6uTR
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05939 for ietf-open-pgp-bks; Fri, 4 Sep 1998 06:40:42 -0700 (PDT)
Received: from geiger.com (dugong10.pcola.gulf.net [205.160.71.73]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA05934 for <[e-mail]>; Fri, 4 Sep 1998 06:40:39 -0700 (PDT)
Received: from whgiii by geiger.com (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id IAA014.23; Fri, 4 Sep 1998 08:53:24 -0500
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Fri, 04 Sep 1998 08:53:07 -0500
To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: Re: Revising RFC 2015
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b50 
Sender: [e-mail]
Precedence: bulk

In <[e-mail]>, on 09/04/98 
   at 07:22 AM, Kazu Yamamoto ($B;3K\OBI'(B) <[e-mail]> said:

>> > (3) Others
>> 
>> > (3.1) Some people want to encode PGP signature and/or
>> > encrypted message with MIME encoding(e.g not PGP armor
>> > but base64). Should we allow this?
>> 
>> I don't see any benefits from this. 

>And I don't see any benefits of PGP armor when used to encode detached
>signatures. Note I can see benefits of PGP armor when used to encode
>encrypted message for backward compatibility.

We are not bringing up this old ghost are we? Every PGP implementation to
date uses ASCII-Armor, it is there and everyone has the code for it. Using
anything other than Ascii-Armor for 8bit to 7bit conversion of PGP packets
only complicates the issue.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA04652 for ietf-open-pgp-bks; Fri, 4 Sep 1998 05:36:39 -0700 (PDT)
Received: from work1.rhrz.uni-bonn.de (work1.rhrz.uni-bonn.de [131.220.16.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04646 for <[e-mail]>; Fri, 4 Sep 1998 05:36:14 -0700 (PDT)
Received: from sobolev.rhein.de ([e-mail] [131.220.244.242]) by work1.rhrz.uni-bonn.de (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id OAA32580 for <[e-mail]>; Fri, 4 Sep 1998 14:41:03 +0200
Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU) id OAA31880 ; Fri, 4 Sep 1998 14:38:25 +0200
Date: Fri, 4 Sep 1998 14:38:25 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: Revising RFC 2015
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.94.4i
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Executive summary:

- I'm dropping my pkalg suggestion.
- There seems to be consensus on micalg.
- A suggestion with respect to ASCII armor and and binary
  representation of PGP objects is made.



  
On Fri, Sep 04, 1998 at 07:22:49AM +0900, Kazu Yamamoto
wrote:

> If the purpose of the pkalg parameter is to distinguish
> PGP format version in MUA level, how about version
> control that I mentioned? 

You got me on this one.  Ok, just forget what I wrote
about different PGP versions.

> (e.g The pgpmime-version parameter for
> application/pgp-signature.) This approach is, I think,
> symmetric if we will decide Version: in
> application/pgp-encrypted.

Let me elaborate my point in a different manner.  We have
several layers between which we should distinguish:

1. Inner PGP packets.  These beasts consist of a packet
   type, version byte, and lots of information.  What
   packets are handled depends from implementation to
   implementation.  E.g., pgp 2 only handles v2 packets,
   OpenPGP compliant software handles v2 and v3 packets,
   etc.

   Most important, implementations should be able to
   graciously bail out upon unknown packets or packet
   versions.

2. Outer PGP packets.  By this, I denote the encapsulation
   of "inner packets", mostly consisting of the packet tag
   and length bytes.

   A new style outer packet can carry any inner packet; an
   old style outer packet an carry any inner packet with a
   3-bit packet tag.

   PGP 2 is about the only implementation which can't
   handle new-style outer packets.  It should be pretty
   simple to add this support (Lutz, have you done it in
   2.6.3in?), so we can IMTAO assume that pretty much
   every implementation in common use can handle these
   packets sooner or later.

(Both are called "packet" in the OpenPGP draft.  Maybe we
should change this in the next version?)
   
3. Packet representation.  PGP knows about two of them:
   ASCII armor and binary.

4. MIME encoding.  This is the encoding we apply at the
   MIME level.

5. MIME encapsulation.

Layers 1-3 (including ascii armor for signatures) are
specified in the OpenPGP draft and should be handled as
mostly opaque by a PGP/MIME text (they are by RFC 2015).
If there are problems on these layers, they should be
dealt with in the next generation OpenPGP RFC.

Layers three and four are pretty much the interface
between MUA and PGP application.  Essentially, one of the
two mappings applied is usually the identity, while the
other one is more or less base64.


Now, let's revisit the version control problem.

Three things can happen with the content types currently
supported by PGP/MIME:

- Alice signs a message with a key and/or signature format
  which is not understood by Bob's software.  In this
  case, Bob's software will kindly bail out and tell him
  that the signature can't be verifyed for this and that
  reason.  Nevertheless, Bob's MUA will be able to display
  the text of the message since the message is present in
  MIME clear-text.

  Clearly, this is a layer 1 incompatibility.

- Alice encrypts a message with Bob's public key and sends
  it to Bob.  Now, this is an issue already dealt with in
  the OpenPGP draft, so it's out of the scope of PGP/MIME.

- Alice sends a public key to Bob, but Bob's PGP version
  is not able to handle this kind of public key.  Well,
  that's tough luck, so they won't be able to communicate
  securely.

  Once again, this is a problem on layer 1.

All this means that there are no version control issues to
be dealt with on the MIME layer, so I think we should
leave them out.

Now, for the MIME parameters.  If we apply the model
above, the pkalg parameter I proposed for signature body
parts should be left out.

I'm completely clear about the fact that this leaves MUAs
who support several back-ends in parallel in the rain;
such software would have to try every back-end in turn, or
implement a back-end selection on the lower levels on the
protocol.

About micalg, you write:

> What I wanted to say is that the parameter itself seems
> less useful than we expected. The micalg parameter is
> defined with the hope that it is useful for one pass
> verification. But I don't know any implementations use
> it.

> Since future implementations may make use of this
> parameter, I'm not particular to this topic.

OK, fine with me.  Can I state the consensus that we leave
everything as it is now and simply add the new hash
algorithms?

>>> (2) Conformance

>>> (2.1) What kinds of algorithm (for symmetric crypt,
>>> asymmetric crypt, hash) is preferred when generated?

>>> (2.3) What kind of actions should be taken if MUA
>>> receives unrecognized PGP packets?

>>> (2.4) Generating: what kind of content-type must MUA be
>>> able to generate? If MUA can sign only text/plain, is it
>>> conformable?

>>> (2.5) Accepting: what kind of content-type must MUA be
>>> able to handle? If MUA can't verify signed text/plain
>>> under multipart/mixed, is it conformable?

> This is not a format issue but a standardization issue.
> Thus certainly protocol issue. Recently, many other
> protocols define minimum conformant set for generating
> and accepting.

Let's revisit these points, and let's think layers while
doing so.

2.1, 2.2 and 2.3 are clearly issues on layers one and two,
so I'd consider them to be outside the scope of the
PGP/MIME spec.

2.4 and 2.5 are yet another category: Here, you are
dealing with general MIME handling.  Now, this is an issue
to be handled in the "generic" MIME documents, but once
again not in a PGP/MIME text.  For the purpose of
PGP/MIME, we can simply assume that a MUA should behave
according to the generic texts.

>>> (3) Others

>>> (3.1) Some people want to encode PGP signature and/or
>>> encrypted message with MIME encoding(e.g not PGP armor
>>> but base64). Should we allow this?

>> I don't see any benefits from this. 

> And I don't see any benefits of PGP armor when used to
> encode detached signatures. Note I can see benefits of
> PGP armor when used to encode encrypted message for
> backward compatibility.

That's correct, but:

>> On the other hand, this would break existing software
>> which relies on the content-transfer-encoding
>> restrictions in RFC 2015. => Don't do this.

> But many implementation of PGP/MIME can handle it (e.g.
> encoded signature with base64), I guess. At least, my
> implementation can do it though it is not my intention.

It's nice that your implementation has this extension of
the required behaviour, making it more robust.  But other
implementations which comply to the current RFC may _not_
have this extension.  We should _not_ deliberately break
that software without good reasons.

Additionally, there is the consistency argument: I don't
think having different content transfer encoding
restrictions for every content type we define is a good
thing.

So if we want to drop ASCII armor on the long run, we
should do so _everywhere_.

A suggestion on this topic:

- Implementations MUST be able to accept ASCII armor
  representations of PGP objects.  They SHOULD be able to
  accept the binary representation.

- Implementations MUST be able to generate ASCII armor
  representations, and they SHOULD NOT generate the binary
  representation.

This should open a smooth upgrade path for the case that
ASCII armor is finally dropped from some future version of
the OpenPGP document.

>>> (4.1) Why not text/pgp?

>>> (4.2) S/MIME doesn't use multipart/encrypted. Why does
>>> PGP/MIME?

> No. RFC is the best place to answer any technical
> questions. 

Correct.  But RFCs are _not_ the best place to extensively
discuss the rationale behind certain basic decisions.
Specifically, an RFC which is merely a revised version of
an existing one should not start to explain the design
decisions behind that existing RFC.  (IMHO)

>>> (5.2) No RFC says that the protocol paramter is
>>> case-insensitive.

>> So it isn't.  Where's the problem here?

> MIME clearly defines any MIME parameters are
> case-*sensitive* if it is not defined so. And RFC 1847
> doesn't say the protocol parameter is case-insensitive.

So it's case-sensitive in PGP/MIME as well, that's what
I've said.  Where's the problem with that?

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10453 for ietf-open-pgp-bks; Thu, 3 Sep 1998 17:03:07 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10448; Thu, 3 Sep 1998 17:03:06 -0700 (PDT)
Received: from [129.46.172.254] (jnoerenberg-mac.qualcomm.com [129.46.172.254]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA07299; Thu, 3 Sep 1998 17:06:44 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04101402b214d70adcdb@[129.46.172.254]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Eudora [Macintosh version 4.1a20-10.98]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Thu, 3 Sep 1998 16:32:11 -0700
To: Jon Callas <[e-mail]>
From: "John  W. Noerenberg" <[e-mail]>
Subject: Re: language tag
Cc: Paul Hoffman / IMC <[e-mail]>, Jon Callas <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

At 1:52 PM -0700 9/3/98, Jon Callas wrote:
>I've already started a -08 draft, on the off chance it's needed. The only
>things in it are Ulf Moeller's implementation note, and adding an L to all
>the constants in the CRC sample code. Does anyone else have an opinion
>anout the words "human-readable"?

Leave them in.  I took the interpretation on rendering UTF-8 that you did.

john noerenberg
[e-mail]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10444 for ietf-open-pgp-bks; Thu, 3 Sep 1998 17:02:39 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10440 for <[e-mail]>; Thu, 3 Sep 1998 17:02:39 -0700 (PDT)
Received: from [129.46.172.254] (jnoerenberg-mac.qualcomm.com [129.46.172.254]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA07407 for <[e-mail]>; Thu, 3 Sep 1998 17:06:55 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04101405b214d894399a@[129.46.172.254]>
X-Mailer: Eudora [Macintosh version 4.1a20-10.98]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Thu, 3 Sep 1998 16:41:26 -0700
To: [e-mail]
From: "John  W. Noerenberg" <[e-mail]>
Subject: Watch for IETF Last Call
Sender: [e-mail]
Precedence: bulk

I expect to see an IETF Last Call announcement on IETF-Announce soon.  Jeff
Schiller plans to ask for one now that he has the -07 draft.

john noerenberg
[e-mail]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10104 for ietf-open-pgp-bks; Thu, 3 Sep 1998 16:18:46 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10100 for <[e-mail]>; Thu, 3 Sep 1998 16:18:44 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id IAA03541 for <[e-mail]>; Fri, 4 Sep 1998 08:23:34 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id IAA03421 for <[e-mail]>; Fri, 4 Sep 1998 08:23:33 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id IAA04154 for <[e-mail]>; Fri, 4 Sep 1998 08:23:33 +0900 (JST)
To: [e-mail]
Subject: Re: Revising RFC 2015
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Thu, 3 Sep 1998 20:37:20 +0200" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93pre4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Fri, 04 Sep 1998 07:22:49 +0900
X-Dispatcher: imput version 980903(IM100pre5)
Lines: 190
Sender: [e-mail]
Precedence: bulk

From: Thomas Roessler <[e-mail]>
Subject: Revising RFC 2015
Date: Thu, 3 Sep 1998 20:37:20 +0200

> >- We may wish to require another parameter with the
> >  application/pgp-signature body parts, namely, "pkalg".
> >  This parameter would identify the public key algorithm
> >  used to generate the signature, e.g., rsa, elgamal, dsa,
> >  etc.
> 
> >  The rationale behind this is that mail user agents may
> >  wish to invoke different external OpenPGP
> >  implementations to verify different kinds of signatures
> >  - e.g., pgp 2 for RSA/MD5, pgp 5 for DSA/SHA1, and gpg
> >  for RSA/RMD160, RSA/SHA1, and so forth.

If the purpose of the pkalg parameter is to distinguish PGP format
version in MUA level, how about version control that I mentioned? (e.g
The pgpmime-version parameter for application/pgp-signature.)  This
approach is, I think, symmetric if we will decide Version: in
application/pgp-encrypted.

> > This is true only when we use the PGP program only. At
> > the last meeting, three people raised their hands to tell
> > implementation of OpenPGP. One of them is GNUPG, I
> > believe. We should be very careful to design PGP/MIME
> > nowadays.
> 
> There is no problem with different implementations - all
> of them should support the same message format (namely,
> OpenPGP).  Command line interfaces and similar issues are
> outside of the scope of this discussion.

I have not discussed command line interface issue. My point is that
implementors are free of how to implement PGP/MIME if it is
conformable to the spec.

I seemds that you assume that MUA interacts underlying a
PGP-conformable program. But it's ok that MUA itself has an ability to
produce PGP format. 

Explanation that everything is fine if you use PGP or GNUPG is not
appealing to me.

Again, my point is that we should be very careful when design PGP/MIME
based on PGP 5. We should not say that it's ok becase the PGP program
can handle it correctly.

> > Yes. But I'm very suspicious that this parameter useful.
> > Anyway, such discussion is not for PGP/MIME but for
> > architecture of security
> 
> Could you please elaborate?  This parameter is as clear as
> the signature block, and it repeats information present
> inside this signature block.

Maybe you may misunderstand my point. You proposed new values. It's
great. Thanks.

What I wanted to say is that the parameter itself seems less useful
than we expected. The micalg parameter is defined with the hope that
it is useful for one pass verification. But I don't know any
implementations use it.

Since future implementations may make use of this parameter, I'm not
particular to this topic.

But again, if micalg is really meaningless, we should feedback this to
RFC 1847.

> Additionally, Kazu gave the following list of problems:
> 
> > (1) version control
> 
> > (1.1) PGP packet format changed. Should we label
> > "Version: 2" for multipart/encrypted?
> 
> > (1.2) How about multipart/signed? Actually, the armor
> > format for detached signatures changed.
> 
> > (1.3) What kind of actions should be taken for each
> > version?  Is it OK for OpenPGP/MIME MUA to ignore
> > PGP/MIME messages?
> 
> > (1.4) If mismatch happens between the micalg parameter
> > and PGP signature, what should we do?
> 
> The old PGP format is a proper subset of the new one, so
> MUA and crypto software which handle OpenPGP properly will
> at least be able to properly decrypt and verify material
> generated by old PGP versions.

It's nice if RFC2015 aware (but not aware to PGP/MIME based on PGP 5)
program can skip further processing according to Version: 2.

And if your observations are correct, it means that many defined
parameber of RFC 2015 is meaningless.

> > (2) Conformance
> 
> > (2.1) What kinds of algorithm (for symmetric crypt,
> > asymmetric crypt, hash) is preferred when generated?
> 
> > (2.2) What is the relationship between *preferred xxx
> > algorithm* in PGP signature for each user and the
> > conformance of (2.1)?
> 
> > (2.3) What kind of actions should be taken if MUA
> > receives unrecognized PGP packets?
> 
> > (2.4) Generating: what kind of content-type must MUA be
> > able to generate? If MUA can sign only text/plain, is it
> > conformable?
> 
> > (2.5) Accepting: what kind of content-type must MUA be
> > able to handle? If MUA can't verify signed text/plain
> > under multipart/mixed, is it conformable?
> 
> This is not an issue of the message format proper, IMHO.
> Anyways, such MUAs are either crippled (2.4) or simply
> unable to handle conforming messages (2.5).

This is not a format issue but a standardization issue. Thus certainly
protocol issue. Recently, many other protocols define minimum
conformant set for generating and accepting.

> > (3) Others
> 
> > (3.1) Some people want to encode PGP signature and/or
> > encrypted message with MIME encoding(e.g not PGP armor
> > but base64). Should we allow this?
> 
> I don't see any benefits from this. 

And I don't see any benefits of PGP armor when used to encode detached
signatures. Note I can see benefits of PGP armor when used to encode
encrypted message for backward compatibility.

>  On the other hand,
> this would break existing software which relies on the
> content-transfer-encoding restrictions in RFC 2015. =>
> Don't do this.

Maybe. Bute many implementation of PGP/MIME can handle it
(e.g. encoded signature with base64), I guess. At least, my
implementation can do it though it is not my intention.

> > (4.1) Why not text/pgp?
> 
> > (4.2) S/MIME doesn't use multipart/encrypted. Why does
> > PGP/MIME?
> 
> I guess this should rather go to news.answers.

No. RFC is the best place to answer any technical questions. And if
such observations will be included in the new PGP/MIME RFC, the same
discussion will never repeat.

> > Is it practical? Who has implemented such complex
> > mechanism?
> 
> It has been done.  Just parse the message/rfc822
> attachment, go through the attachment tree, adjust the
> leafs' encodings, set the nodes' (multipart/*, message/*)
> encodings to 7bit and write the whole thing to disk.  

Great. Mutt can encode, for instance, a message, to be attached then
signed, which contains multipart whose second part is 8bit text, to
7bit? How about very recursed messages?

> Not too beautiful, but feasible.

Interesting. You are the first European for me to accept RFC 1847's
7bit restriction. :-)

I'm not a European and I don't use 8bit charset usually. Nonetheless,
I disagree with RFC 1847's 7bit restriction. The world is really
coming back to 8bit transportation while 7bit transportation spread in
the beginning of the MIME days.

> > (5.2) No RFC says that the protocol paramter is
> > case-insensitive.
> 
> So it isn't.  Where's the problem here?

MIME clearly defines any MIME parameters are case-*sensitive* if it is
not defined so. And RFC 1847 doesn't say the protocol parameter is
case-insensitive.

--Kazu


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09624 for ietf-open-pgp-bks; Thu, 3 Sep 1998 15:23:41 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09620 for <[e-mail]>; Thu, 3 Sep 1998 15:23:39 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id HAA03223 for <[e-mail]>; Fri, 4 Sep 1998 07:28:29 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id HAA01991 for <[e-mail]>; Fri, 4 Sep 1998 07:28:28 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id HAA03142 for <[e-mail]>; Fri, 4 Sep 1998 07:28:28 +0900 (JST)
To: [e-mail]
Subject: Re: language tag
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Thu, 03 Sep 1998 11:37:22 -0700" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93pre4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Fri, 04 Sep 1998 06:27:44 +0900
X-Dispatcher: imput version 980903(IM100pre5)
Lines: 28
Sender: [e-mail]
Precedence: bulk

From: Jon Callas <[e-mail]>
Subject: Re: language tag
Date: Thu, 03 Sep 1998 11:37:22 -0700

> Kazu, does the wording on the "Charset:" header help you? 

Yes. The 07 draft looks very reasonable to me. Thank you.

> Putting a tag in
> there to specify language is something simple that the implementor can do
> to solve this problem. The only other place where there is text is in the
> user id packets, and those are defined to have essentially no format. By 
> convention they are RFC822 names, but they can be X.500 names or anything
> else. It's reasonable to qualify a name with a RFC1766 language tag there
> if you don't want to use romaji.

As Paul answered, language tag is not necessary to be defined. 

It is necessary only for UTF-8 (namely Unicode) to distinguish
CKJ. And self-taging mechanism for UTF-8 is on the table. 

If a character set other than UTF-8 is used, the Charset: header is
enough.

Again, thank you for your revisions.

--Kazu



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA09383 for ietf-open-pgp-bks; Thu, 3 Sep 1998 14:50:19 -0700 (PDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09378; Thu, 3 Sep 1998 14:50:18 -0700 (PDT)
Received: from xedia.com by relay1.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQffhf24618; Thu, 3 Sep 1998 17:54:16 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA23045; Thu, 3 Sep 98 17:53:35 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id RAA19801; Thu, 3 Sep 1998 17:54:15 -0400
Date: Thu, 3 Sep 1998 17:54:15 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: language tag
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Jon" == Jon Callas <[e-mail]> writes:
>.... Does anyone else have an opinion anout the words
> "human-readable"?

I think "human readable" means readable by some humans, once the
collections of electrons in memory are converted to patterns of light
and dark on a display device.  Nothing in a computer is human-readable 
without transducers.  But once you have a transducer, UTF-8 is
human-readable whether it contains USASCII or CJK characters.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08792 for ietf-open-pgp-bks; Thu, 3 Sep 1998 13:51:01 -0700 (PDT)
Received: from fusebox.pgp.com ([161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08787; Thu, 3 Sep 1998 13:51:01 -0700 (PDT)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id NAA11461; Thu, 3 Sep 1998 13:55:16 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 03 Sep 1998 13:52:46 -0700
To: Paul Hoffman / IMC <[e-mail]>, Jon Callas <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: language tag
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 01:33 PM 9/3/98 -0700, Paul Hoffman / IMC wrote:

   No, it is *not* reasonable to use an RFC1766 tag there since there is
   nothing to differentiate the tag from the body. Inline tagging as specified
   in the new draft clearly differentiates what is a language tag from the
   content. It also allows more than one language tag per string, which is
   something that some Asians need if their two names are from different
   languages.

Great. I love not making changes.
   
   I don't think any change is needed. Freel free to take out the
   "human-readable" thing above, but leaving it in won't cause undue damage.
   
I've already started a -08 draft, on the off chance it's needed. The only
things in it are Ulf Moeller's implementation note, and adding an L to all
the constants in the CRC sample code. Does anyone else have an opinion
anout the words "human-readable"?

	Jon


-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08182 for ietf-open-pgp-bks; Thu, 3 Sep 1998 13:28:36 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA08176; Thu, 3 Sep 1998 13:28:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 03 Sep 1998 13:33:18 -0700
To: Jon Callas <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: language tag
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 11:37 AM 9/3/98 -0700, Jon Callas wrote:
>Ummm, I'm not sure I understand. My reading of printing UTF-8 in human
>readable form means that you should apply whatever print transform is
>needed to make it look like text.

Ah, I see what you're saying. Yes, then UTF-8 is "human-readable" in the
same sense that hexadecimal is human-readable. I thought you meant "a
normal human could look at this string and read it", which is not true for
UTF-8 (or hex...).

>The only other place where there is text is in the
>user id packets, and those are defined to have essentially no format. By
>convention they are RFC822 names, but they can be X.500 names or anything
>else. It's reasonable to qualify a name with a RFC1766 language tag there
>if you don't want to use romaji.

No, it is *not* reasonable to use an RFC1766 tag there since there is
nothing to differentiate the tag from the body. Inline tagging as specified
in the new draft clearly differentiates what is a language tag from the
content. It also allows more than one language tag per string, which is
something that some Asians need if their two names are from different
languages.

>I'm willing to put something quick in for IETF last call if it will solve
>the problem. I'm willing to say, "we do it the way they do it" for some
>suitable they. But I don't want to stop progress.

I don't think any change is needed. Freel free to take out the
"human-readable" thing above, but leaving it in won't cause undue damage.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06971 for ietf-open-pgp-bks; Thu, 3 Sep 1998 12:05:31 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06967 for <[e-mail]>; Thu, 3 Sep 1998 12:05:30 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id EAA02453 for <[e-mail]>; Fri, 4 Sep 1998 04:10:18 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id EAA28501 for <[e-mail]>; Fri, 4 Sep 1998 04:10:17 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id EAA00398 for <[e-mail]>; Fri, 4 Sep 1998 04:10:17 +0900 (JST)
To: [e-mail]
Subject: Re: language tag
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: Your message of "Thu, 03 Sep 1998 09:42:54 -0700" <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.93pre4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Fri, 04 Sep 1998 03:09:32 +0900
X-Dispatcher: imput version 980903(IM100pre5)
Lines: 14
Sender: [e-mail]
Precedence: bulk

From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: language tag
Date: Thu, 03 Sep 1998 09:42:54 -0700

> >draft-ietf-openpgp-formats-06.txt defines UTF-8 for each field of PGP
> >packets. Unfortunately, I couldn't find any method to identify
> >language. 
> 
> Please take a look at draft-whistler-plane14, which is in IESG last call.
> It specifies a way to identify languages within UTF-8.

This answers my question. Thanks!

--Kazu


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06738 for ietf-open-pgp-bks; Thu, 3 Sep 1998 11:37:09 -0700 (PDT)
Received: from work1.rhrz.uni-bonn.de (work1.rhrz.uni-bonn.de [131.220.16.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06734 for <[e-mail]>; Thu, 3 Sep 1998 11:37:06 -0700 (PDT)
Received: from sobolev.rhein.de ([e-mail] [131.220.244.9]) by work1.rhrz.uni-bonn.de (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id UAA16638 for <[e-mail]>; Thu, 3 Sep 1998 20:41:46 +0200
Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8/Debian/GNU) id UAA10662 ; Thu, 3 Sep 1998 20:37:20 +0200
Date: Thu, 3 Sep 1998 20:37:20 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Revising RFC 2015
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <v04101412b213b819b493@[129.46.172.254]> <v0410130fb21240569aec@[129.46.172.141]> <[e-mail]> <[e-mail]> <[e-mail]> <v0410130fb21240569aec@[129.46.172.141]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.94.4i
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

This message has been compiled from some private
communications between Kazu Yamamoto, Michael Elkins, John
Noerenberg and myself on the topic of a revision of RFC
2015 ("MIME Security with Pretty Good Privacy (PGP)").  I
have slightly edited the messages; omissions include
consensus on issues being on or off topic and off topic
issues.

Please comment.

tlr


[Begin of old communications.]

I compiled the following list of issues (this is not the
original version; I've added some points):

>- RFC 2015 requires a micalg parameter when producing
>  "multipart/signed; protocol=application/pgp-signature"
>  body parts.  RFC 2015 defines the two hash algorithms
>  pgp-md5 and pgp-sha1, while the current OpenPGP draft
>  knows about some more algorithms (section 9.4).

>- If I understand draft-ietf-openpgp-formats-06 correctly,
>  OpenPGP permits parallel signatures with different hash
>  algorithms applying to one and the same message.  We may
>  wish to permit a comma-separated list of hash algorithms
>  for the micalg parameter.

>  Further pursuing this direction of thought, one may be
>  inclined to permit several application/pgp-signature
>  body parts in a multipart/encrypted attachment, each of
>  them corresponding to a specific micalg.  This micalg
>  parameter should additionally be listed in the
>  Content-Type header of said additional signature parts.

[This one was not in the first version:]

>- We may wish to require another parameter with the
>  application/pgp-signature body parts, namely, "pkalg".
>  This parameter would identify the public key algorithm
>  used to generate the signature, e.g., rsa, elgamal, dsa,
>  etc.

>  The rationale behind this is that mail user agents may
>  wish to invoke different external OpenPGP
>  implementations to verify different kinds of signatures
>  - e.g., pgp 2 for RSA/MD5, pgp 5 for DSA/SHA1, and gpg
>  for RSA/RMD160, RSA/SHA1, and so forth.

[Original list continued.]

>- Section 6.2 of RFC 2015 explicitly mentions PGP 2.x. We
>  may wish to update this to reference the OpenPGP RFC
>  when it comes out - but that's just a nit.

>- RFC 2015 does not explicitly specify what type of PGP
>  signature is to be generated when signing messages
>  (binary document or text document signature).  But
>  that's pretty much a non-problem since the RFC
>  _requires_ user agents to convert texts to canonical
>  format before verifying or generating signatures, thus
>  making text and binary signatures of the message body
>  equivalent.



Kazu's reply to this plus my comments:

>> From the MUA's point of view, pgp 2, pgp 5, and gpg
>> behave pretty much the same way.

> This is true only when we use the PGP program only. At
> the last meeting, three people raised their hands to tell
> implementation of OpenPGP. One of them is GNUPG, I
> believe. We should be very careful to design PGP/MIME
> nowadays.

There is no problem with different implementations - all
of them should support the same message format (namely,
OpenPGP).  Command line interfaces and similar issues are
outside of the scope of this discussion.

[micalg parameter for multipart/signed]

> Yes. But I'm very suspicious that this parameter useful.
> Anyway, such discussion is not for PGP/MIME but for
> architecture of security

Could you please elaborate?  This parameter is as clear as
the signature block, and it repeats information present
inside this signature block.

[binary vs. text signatures]

> Here here here. Some PGP/MIME implementors repeatedly
> asked me this topic. As Thomas said, RFC 2015 is enough.
> But I think it's not readable. It's nice if the next
> PGP/MIME draft will include binary vs text packet format
> discussions. I'm sick of answering this question.



Additionally, Kazu gave the following list of problems:

> (1) version control

> (1.1) PGP packet format changed. Should we label
> "Version: 2" for multipart/encrypted?

> (1.2) How about multipart/signed? Actually, the armor
> format for detached signatures changed.

> (1.3) What kind of actions should be taken for each
> version?  Is it OK for OpenPGP/MIME MUA to ignore
> PGP/MIME messages?

> (1.4) If mismatch happens between the micalg parameter
> and PGP signature, what should we do?

The old PGP format is a proper subset of the new one, so
MUA and crypto software which handle OpenPGP properly will
at least be able to properly decrypt and verify material
generated by old PGP versions.

> (2) Conformance

> (2.1) What kinds of algorithm (for symmetric crypt,
> asymmetric crypt, hash) is preferred when generated?

> (2.2) What is the relationship between *preferred xxx
> algorithm* in PGP signature for each user and the
> conformance of (2.1)?

> (2.3) What kind of actions should be taken if MUA
> receives unrecognized PGP packets?

> (2.4) Generating: what kind of content-type must MUA be
> able to generate? If MUA can sign only text/plain, is it
> conformable?

> (2.5) Accepting: what kind of content-type must MUA be
> able to handle? If MUA can't verify signed text/plain
> under multipart/mixed, is it conformable?

This is not an issue of the message format proper, IMHO.
Anyways, such MUAs are either crippled (2.4) or simply
unable to handle conforming messages (2.5).

> (3) Others

> (3.1) Some people want to encode PGP signature and/or
> encrypted message with MIME encoding(e.g not PGP armor
> but base64). Should we allow this?

I don't see any benefits from this.  On the other hand,
this would break existing software which relies on the
content-transfer-encoding restrictions in RFC 2015. =>
Don't do this.

> (4) FAQ

> (4.1) Why not text/pgp?

> (4.2) S/MIME doesn't use multipart/encrypted. Why does
> PGP/MIME?

I guess this should rather go to news.answers.

> (5) security multipart issue (maybe should feedback to
> RFC 1847)

> (5.1) In many cases, European people exchange their
> Latin-1 messages with CTE: 8bit. But RFC 1847 requires
> objects to be signed be 7bit. How can sign 8bit
> message/rfc822? Ned said that MUA must change 8bit
> message to 7bit. 

Precisely.

> Is it practical? Who has implemented such complex
> mechanism?

It has been done.  Just parse the message/rfc822
attachment, go through the attachment tree, adjust the
leafs' encodings, set the nodes' (multipart/*, message/*)
encodings to 7bit and write the whole thing to disk.  Not
too beautiful, but feasible.

> (5.2) No RFC says that the protocol paramter is
> case-insensitive.

So it isn't.  Where's the problem here?

[End of old communications.]


-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06723 for ietf-open-pgp-bks; Thu, 3 Sep 1998 11:35:54 -0700 (PDT)
Received: from fusebox.pgp.com ([161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06718; Thu, 3 Sep 1998 11:35:54 -0700 (PDT)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id LAA10722; Thu, 3 Sep 1998 11:40:11 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 03 Sep 1998 11:37:22 -0700
To: Paul Hoffman / IMC <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: language tag
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 09:42 AM 9/3/98 -0700, Paul Hoffman / IMC wrote:

   A note to the editors: I found a problem relating to this in reading the
   -07 draft. In 5.2.3.22, you say "in human-readable form (UTF-8)". UTF-8 is
   not human-readable unless every character in the text is US-ASCII. During
   IESG last cally, you should probably strike "in human-readable form" from
   this section.
   
Ummm, I'm not sure I understand. My reading of printing UTF-8 in human
readable form means that you should apply whatever print transform is
needed to make it look like text. It's just as applicable to ASCII as UTF-8
(and in fact that text dates from the days when the spec said ASCII). For
example, 0x4a6f6e407067702e636f6d is the ASCII representation of my return
mail address, but it's less human readable than "[e-mail]" is. If I put
on my spec-lawyer hat and strike "in human-readble form" then it's
acceptable to put the UTF-8 out in hex or ISO-Latin5, even. "Human-readable
form" means to me that you put the bits through whatever transform makes
the right glyphs come out, and that's precisely what we want; it's an
admonition not to eat the daisies. But I'll strike it if that's what gets
us passed.

Kazu, does the wording on the "Charset:" header help you? Putting a tag in
there to specify language is something simple that the implementor can do
to solve this problem. The only other place where there is text is in the
user id packets, and those are defined to have essentially no format. By
convention they are RFC822 names, but they can be X.500 names or anything
else. It's reasonable to qualify a name with a RFC1766 language tag there
if you don't want to use romaji.

I'm willing to put something quick in for IETF last call if it will solve
the problem. I'm willing to say, "we do it the way they do it" for some
suitable they. But I don't want to stop progress.

	Jon





-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06615 for ietf-open-pgp-bks; Thu, 3 Sep 1998 11:21:51 -0700 (PDT)
Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06611 for <[e-mail]>; Thu, 3 Sep 1998 11:21:50 -0700 (PDT)
Received: from localhost (mione@localhost) by boeing.rutgers.edu (8.8.8/8.8.8) with SMTP id OAA07828; Thu, 3 Sep 1998 14:26:39 -0400 (EDT)
Date: Thu, 3 Sep 1998 14:26:39 -0400 (EDT)
From: Tony Mione <[e-mail]>
To: [e-mail]
cc: Tony Mione <[e-mail]>
Subject: Request for updates or new submissions to the PGP implemtation web page
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


It has been some time since I have updated my PGP implementation survey
page. If you have written a package that supports PGP based object
encryption, please fill out a survey form and email it to may so I may add
that product to the web page. If you have filled out a survey but your
product has new features, please send any changes or amendments and they
will be reflected on the page. To find a blank survey form and the
implementation page as it currently stands, go to:

http://www-ns.rutgers.edu/~mione/openpgp/

Currently, the following products are listed on the page:

Cryptix
Mew
Privtool
pgp.el
MailCat
NoCeM
PGP 2.6.3in
PGPin
Cryptlib
Decrypt
Potato
Jack B. Nymble
Information Heap
PGPlib
Mapil
E-Secure
OPGP (formerly Ciphercopia)
G10
PGPsdk (also PGP 5.5 from NAI)


Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[e-mail]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F       ***** Important: John 17:3 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNe7fWPMKRuSgNA5pAQFtuAMAvf0EEMo4HykaqyGZ1YSiLiwCcd5dPClQ
CVf5P4Rvb5U3SVIRrhUDF66wBklZOuazD2mj3dHDj9WG2WsDnGk2iaCEjayeEX+4
bztCsZb3J4q9HleQtg9BJWrEzUOMDI/K
=cl2l
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06519 for ietf-open-pgp-bks; Thu, 3 Sep 1998 11:12:52 -0700 (PDT)
Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06515 for <[e-mail]>; Thu, 3 Sep 1998 11:12:51 -0700 (PDT)
Received: from localhost (mione@localhost) by boeing.rutgers.edu (8.8.8/8.8.8) with SMTP id OAA07779; Thu, 3 Sep 1998 14:17:38 -0400 (EDT)
Date: Thu, 3 Sep 1998 14:17:38 -0400 (EDT)
From: Tony Mione <[e-mail]>
To: [e-mail]
cc: Tony Mione <[e-mail]>
Subject: Call for Laundry List
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


At the IETF OpenPGP WG meeting last week, it was announced that the formats
draft (draft-ietf-openpgp-formats-07.txt) will be going to the IESG
shortly. Since many items were put off as too complex to hash out during
the deliberations involved in writing this document, it was thought that
once this is published as an rfc, the OpenPGP Working Group should start
working on the next version of the document. That version will include all
the really cool features that we didn't have time to do in the first pass.
For instance, one idea that came up was to include an 'alternate user id'
and allow varying data types including gif or jpg images of the key owner.

I have been tasked with gathering the 'Laundry List' of issues we would
like to revisit as a group. I am requesting that if you voiced an idea that
got 'put off until the next version of OpenPGP' sometime since the OpenPGP
working group formed, please send a brief description of those ideas either
directly to me. I will gather the ideas into a list and post that list to
the ietf-open-pgp mailing list in about one months time. I would like to
close the period for submissions around October 1st. I will be willing to
take ideas for a short time after that, they just will not be in the first
list sent to the working group.

I may also post the list on my web page. If I do that, I will announce the
url to the list as well.

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[e-mail]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F       ***** Important: John 17:3 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNe7dOPMKRuSgNA5pAQEM0gMAg5JMhmPA4w6Kk5FeigJgznITJBcjTVWl
S47Psh9lWnVdqL8Dlc/58CXdRG1NlrCVr8rcjlYIczRgeuz2hurrcPm8KD66URRF
YBG4/53FaBZkGnCpdzNKNn6t5fOv6tDo
=Su1i
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05430 for ietf-open-pgp-bks; Thu, 3 Sep 1998 09:38:11 -0700 (PDT)
Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA05426 for <[e-mail]>; Thu, 3 Sep 1998 09:38:10 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 03 Sep 1998 09:42:54 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: language tag
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 07:44 PM 9/3/98 +0900, =?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?= wrote:
>draft-ietf-openpgp-formats-06.txt defines UTF-8 for each field of PGP
>packets. Unfortunately, I couldn't find any method to identify
>language. 

Please take a look at draft-whistler-plane14, which is in IESG last call.
It specifies a way to identify languages within UTF-8.

>RFC 2266 suggests that language tag defined in RFC 1766 should be
>provided in each protocols. Please define RFC 1766-like means to
>specify language.

This is not possible. The text chunks in OpenPGP are not MIME chunks, they
are bare strings. You have to use inline language tagging, as specified in
draft-whistler-plane14.

A note to the editors: I found a problem relating to this in reading the
-07 draft. In 5.2.3.22, you say "in human-readable form (UTF-8)". UTF-8 is
not human-readable unless every character in the text is US-ASCII. During
IESG last cally, you should probably strike "in human-readable form" from
this section.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA02097 for ietf-open-pgp-bks; Thu, 3 Sep 1998 07:44:48 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02093 for <[e-mail]>; Thu, 3 Sep 1998 07:44:46 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03397; Thu, 3 Sep 1998 10:49:01 -0400 (EDT)
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-formats-07.txt
Date: Thu, 03 Sep 1998 10:49:00 -0400
Sender: [e-mail]
Precedence: bulk

--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		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-formats-07.txt
	Pages		: 59
	Date		: 02-Sep-98
	
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the OpenPGP format. It is not a step-by-step cookbook for writing an
   application. It describes only the format and methods needed to
   read, check, generate, and write conforming packets crossing any
   network. It does not deal with storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.
 
   Open-PGP software uses a combination of strong public-key and
   symmetric cryptography to provide security services for electronic
   communications and data storage.  These services include
   confidentiality, key management, authentication, and digital
   signatures. This document specifies the message formats used in
   OpenPGP.

Internet-Drafts are 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-formats-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-formats-07.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-formats-07.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00391 for ietf-open-pgp-bks; Thu, 3 Sep 1998 04:40:15 -0700 (PDT)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00387 for <[e-mail]>; Thu, 3 Sep 1998 04:40:13 -0700 (PDT)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA24686 for <[e-mail]>; Thu, 3 Sep 1998 20:44:52 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA21716 for <[e-mail]>; Thu, 3 Sep 1998 20:44:52 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA21581 for <[e-mail]>; Thu, 3 Sep 1998 20:44:52 +0900 (JST)
To: [e-mail]
Subject: language tag
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
X-Mailer: Mew version 1.93pre4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 03 Sep 1998 19:44:07 +0900
X-Dispatcher: imput version 980903(IM100pre5)
Lines: 12
Sender: [e-mail]
Precedence: bulk

draft-ietf-openpgp-formats-06.txt defines UTF-8 for each field of PGP
packets. Unfortunately, I couldn't find any method to identify
language. 

RFC 2266 suggests that language tag defined in RFC 1766 should be
provided in each protocols. Please define RFC 1766-like means to
specify language.

Otherwise, we can't distinguish Japanese/Korean/Chinese.

--Kazu



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19651 for ietf-open-pgp-bks; Tue, 1 Sep 1998 11:17:47 -0700 (PDT)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19647 for <[e-mail]>; Tue, 1 Sep 1998 11:17:46 -0700 (PDT)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id LAA17954; Tue, 1 Sep 1998 11:20:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 01 Sep 1998 11:10:54 -0700
To: [e-mail] (Ulf =?iso-8859-1?Q?M=F6ller?= ), [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: comments on the format 06 draft
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id LAA19648
Sender: [e-mail]
Precedence: bulk

At 01:18 AM 9/1/98 +0200, Ulf Möller wrote:
   Are there going to be more revisions of the draft?

The -07 draft is at the editor's desk, you should see their note here today
or tomorrow. This is the draft that's going to the IESG. I slipped in the
correction to the CRC calculation, and made some changes for Kazu with
regard to character set.

	Jon


-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17842 for ietf-open-pgp-bks; Tue, 1 Sep 1998 07:37:36 -0700 (PDT)
Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17838 for <[e-mail]>; Tue, 1 Sep 1998 07:37:35 -0700 (PDT)
Received: by brickwall.ceddec.com id <43012>; Tue, 1 Sep 1998 10:40:16 -0400
Date: Tue, 1 Sep 1998 10:41:56 -0400
From: [e-mail]
X-Sender: nobody@mars
To: Ulf =?iso-8859-1?Q?M=F6ller?= <[e-mail]>
cc: [e-mail]
Subject: Re: comments on the format 06 draft
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id HAA17839
Sender: [e-mail]
Precedence: bulk

On Mon, 31 Aug 1998, Ulf [iso-8859-1] Möller wrote:

> BTW, why do clear-signed messages have a "Hash:" header? The hash
> algorithm is given in the signature packet.

So that you can start hashing as you process the message.  When there was
only one hash, it didn't matter.  Now you would need to do several hashes
if you wanted to process it as a filter so you would be ready when you
hit the signatures.  Otherwise you need to know which hashes to use in
advance (the logic behind the one-pass signature header).

(Note that the spec might not be clear, but if two signatures are
appended, one with MD5 and one with SHA1, both must be specified in the
Hash: header.  No Hash: header implies MD5, but any Hash: header implies
the list is complete).