Subject: 8bit text in Comment line (i18n)

From: John Kane <[email-masked]>
Date: Sun, 29 Jul 2001 03:48:24 -0400

Some of the KDE people (Mark Mutz, Ingo Kloecker) noted:
http://lists.gnupg.org/pipermail/gnupg-users/2001-July/009397.html

that ascii-armor comment lines may contain non-7-bit text.
It is not clear whether this is a "SHOULD warn" situation.

I see no clause defining the charset of text in Armor Headers.
Should an armored block be constrained to use only 7-bit
mail-safe characters, or should it be stated that Armor
Headers may be in UTF-8, or native charset, or what?

Either user-defined text in Armor Headers MAY contain
non-7-bit characters, or SHOULD NOT, or MUST NOT.

If non-7-bit text is allowed, there ought to be a note in
2440/6.2 which warns that the use of an 8-bit charset
will make the 'armored' output non-mail-safe.

---

From: Florian Weimer <[email-masked]>
Date: 29 Jul 2001 10:40:48 +0200

> I see no clause defining the charset of text in Armor Headers.

All text in RFC 2440 messages is encoded in UTF-8, unless otherwise
stated.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 29 Jul 2001 11:33:41 +0200

On 2001-07-29 03:48:24 -0400, John Kane wrote:

>Should an armored block be constrained to use only 7-bit mail-safe 
>characters, or should it be stated that Armor Headers may be in 
>UTF-8, or native charset, or what?

There's a reason why it's called ASCII armor, and not UTF-8 armor, 
and at least PGP/MIME relies on ASCII armor being actually 
restricted 7bit characters.

I don't think that vanity armor headers in arbitrary character sets 
are even remotely worth the hassles and effort which they generate.

-- 
Thomas Roessler                        http://log.does-not-exist.org/

---

From: John Kane <[email-masked]>
Date: Sun, 29 Jul 2001 18:46:27 -0400

> arbitrary character sets [aren't] even remotely worth the hassles

Amen.  But in rfc2440bis-02, this is the complete definition:

     Concatenating the following data creates ASCII Armor
and:
     - "Comment", a user-defined comment.

There is nothing in the spec which requires an implementation to
drop non-ascii characters.  Currently, an implementation which
emits 0x80-0xFF octets in an Armor Header is rfc2440-compliant.
I don't like this, but that's the way it reads.

Certain implementations are already emitting native 8-bit text
in comments.  (...presumably by accident...)

If you want to ensure that ASCII Armor blocks contain only
the basic 95 printable characters, you'll need to put something
in section 6.2 which says that the 'data' which is concatenated
to form ASCII Armor must itself be pure 0x20-0x7E ASCII.
Currently this is not part of the spec.

Even something as simple as:
     "Comment", a user-defined 7-bit ASCII comment.
might be sufficient.

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 30 Jul 2001 11:23:57 +0200

On 2001-07-29 18:46:27 -0400, John Kane wrote:

>If you want to ensure that ASCII Armor blocks contain only the 
>basic 95 printable characters, you'll need to put something in 
>section 6.2 which says that the 'data' which is concatenated to 
>form ASCII Armor must itself be pure 0x20-0x7E ASCII. Currently 
>this is not part of the spec.

Precisely.  Jon?

---

From: Jon Callas <[email-masked]>
Date: Mon, 30 Jul 2001 17:38:48 -0700

>>this is not part of the spec.

Forgive me for being dense, but I don't completely understand the problem.
The armor portion of ASCII armor completely defines what is there, so that
they pass through some potentially damaging transport.

However, the comment line is precisely that -- it's a comment for people,
not for the machines. In practice, it's a bumper-sticker field that people
use to advertise their favorite implementation or the slogan of the week.
If it gets mangled by a transport, it doesn't cause the protocol any
problems. The ASCII armor still transfers the secure object.

I don't see the problem in the comment line being UTF-8 (and it never
occurred to me that it wasn't). After all, there's an IETF meta-rule that
text is supposed to be UTF-8 unless there's a really, really good reason
for it not to be. So I have to ask -- why shouldn't someone be able to put
UTF-8 there? What's wrong with it?

	Jon

---

From: John Kane <[email-masked]>
Date: Mon, 30 Jul 2001 22:17:59 -0400

Jon Callas wrote:
 > If it gets mangled by a transport, it doesn't cause
 > the protocol any problems.

In some environments, 0x8A translates to 0x0A/CRLF.

The KDE / Mime team discovered rfc2440 implementations
which emit comments in the native 8-bit charset.
This breaks Mime unless they re-encode the entire block
in radix-64, which conflicts with a PGP/Mime requirement
that certain OpenPGP Armored formats MUST be left in
their native "----- BEGIN ... ----- END" format.

They can't use the '=FF' mechanism because it would
encode the '=' terminators in the armor.

PGP/Mime needs its ASCII Armor to be pure 7-bit ASCII.

---

From: Jon Callas <[email-masked]>
Date: Mon, 30 Jul 2001 20:40:33 -0700

>PGP/Mime needs its ASCII Armor to be pure 7-bit ASCII.

Here are questions I have:

Is this an implementation problem, or a standard problem?

How many people outside of North America going to scream if we all of a
sudden limit it to 7-bit?

Is UTF-7 an answer, or a disgusting hack (having to parse two UTFs)?

	Jon

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 31 Jul 2001 07:28:45 +0200

On 2001-07-30 17:38:48 -0700, Jon Callas wrote:

>However, the comment line is precisely that -- it's a comment for 
>people, not for the machines. 

Embedded in data which should normally never be presented to people 
in that form.  A very useful concept, indeed.

>In practice, it's a bumper-sticker field that people use to 
>advertise their favorite implementation or the slogan of the week. 
>If it gets mangled by a transport, it doesn't cause the protocol 
>any problems. The ASCII armor still transfers the secure object.

True.  But still, with e-mail transfer, an utf-8 comment header 
would make it necessary to MIME-encode ASCII armor, which sounds 
extremely ugly, and would possibly kind of break PGP/MIME's 
tradition (ever since RFC 2015) of using ASCII armor _instead_ _of_ 
MIME encodings.

---

From: Werner Koch <[email-masked]>
Date: 31 Jul 2001 09:39:15 +0200

> Is this an implementation problem, or a standard problem?

It is a matter how the implementation is used to create an rfc2015
compliant message.  Some translations of GnuPG do translate the
default comment string and then you might see non ascii characters.

The solution is to use "gpg --comment '' ..." to disable the armor
commentline or use sed to cut it out later.

So it is definitely not a standard problem.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

To: Jon Callas <[email-masked]>
Cc: John Kane <[email-masked]>, [email-masked]
Subject: Re: Forbidding 8bit text in Armor comments
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 31 Jul 2001 09:39:15 +0200
Lines: 19
Sender: [email-masked]

> Is this an implementation problem, or a standard problem?

It is a matter how the implementation is used to create an rfc2015
compliant message.  Some translations of GnuPG do translate the
default comment string and then you might see non ascii characters.

The solution is to use "gpg --comment '' ..." to disable the armor
commentline or use sed to cut it out later.

So it is definitely not a standard problem.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

Date: Tue, 31 Jul 2001 07:28:45 +0200
From: Thomas Roessler <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: John Kane <[email-masked]>, [email-masked]
Subject: Re: Forbidding 8bit text in Armor comments
Mail-Followup-To: Jon Callas <[email-masked]>, John Kane <[email-masked]>, [email-masked]
Sender: [email-masked]

Date: Mon, 30 Jul 2001 20:40:33 -0700
To: John Kane <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Forbidding 8bit text in Armor comments
Cc: [email-masked]
Sender: [email-masked]

	Jon

Date: Mon, 30 Jul 2001 22:17:59 -0400
From: John Kane <[email-masked]>
To: Jon Callas <[email-masked]>
CC: [email-masked]
Subject: Re: Forbidding 8bit text in Armor comments
Sender: [email-masked]

Date: Mon, 30 Jul 2001 17:38:48 -0700
To: Thomas Roessler <[email-masked]>, John Kane <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Forbidding 8bit text in Armor comments
Cc: [email-masked]
Sender: [email-masked]

	Jon

Date: Mon, 30 Jul 2001 11:23:57 +0200
From: Thomas Roessler <[email-masked]>
To: John Kane <[email-masked]>, Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Forbidding 8bit text in Armor comments
Mail-Followup-To: John Kane <[email-masked]>, Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

Precisely.  Jon?

Date: Sun, 29 Jul 2001 18:46:27 -0400
From: John Kane <[email-masked]>
To: [email-masked]
Subject: Re: 8bit text in Comment line (i18n)
Sender: [email-masked]

Date: Sun, 29 Jul 2001 11:33:41 +0200
From: Thomas Roessler <[email-masked]>
To: John Kane <[email-masked]>
Cc: [email-masked]
Subject: Re: 8bit text in Comment line (i18n)
Mail-Followup-To: John Kane <[email-masked]>, [email-masked]
Sender: [email-masked]

To: [email-masked]
Subject: Re: 8bit text in Comment line (i18n)
From: Florian Weimer <[email-masked]>
Date: 29 Jul 2001 10:40:48 +0200
Lines: 11
Sender: [email-masked]

Date: Sun, 29 Jul 2001 03:48:24 -0400
From: John Kane <[email-masked]>
To: [email-masked]
Subject: 8bit text in Comment line (i18n)
Sender: [email-masked]

Date: Wed, 25 Jul 2001 18:34:46 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Notation data suggestion for rfc2440bis-02
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I have a suggestion for rfc2440bis, section 5.2.3.16 (Notation Data).

The design to divide the notation "name" namespace into IETF and
user-controlled spaces is very good as it allows for people to add
their own notations that may or may not be applicable to the world at
large, but are still usable for anyone who is interested.

Since the user space naming scheme is, in effect, an email address
(being a name @ a DNS domain), I'd like to suggest adding something
like this:

   Since the user name space is in the form of an email address,
   implementors MAY wish to arrange for that address to reach a person
   who can be consulted about the use of the named tag.  Note that due
   to UTF-8 encoding, not all valid user space name tags are valid
   email addresses.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Mon, 23 Jul 2001 23:26:57 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Question about Notation Data and URLs
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Given the improvement to the Notation Data packet in
draft-ietf-openpgp-rfc2440bis-02, I am curious as to the future use of
the Policy URL and Preferred keyserver packets.

Instead of having additional packet types, wouldn't it be simpler to
have a notation with the name being "POLICYURL" or the like, and the
value being the URL?

I'm aware that Policy URL and Preferred keyserver already existed in
rfc2440, and that some code already uses them which is probably enough
of a reason not to get rid of them right there :) It would be nice
though code-wise to be able to put all attributes like that in a
single type of packet.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-mime-08.txt
Date: Mon, 23 Jul 2001 06:37:58 -0400
Sender: [email-masked]

--NextPart

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

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-08.txt
	Pages		: 15
	Date		: 20-Jul-01
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[email-masked]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

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

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

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-mime-08.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: MIME Security with OpenPGP to Proposed Standard
Date: Thu, 19 Jul 2001 16:52:04 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'MIME Security with OpenPGP'
<draft-ietf-openpgp-mime-07.txt> as a Proposed Standard.  This document
is the product of the An Open Specification for Pretty Good Privacy
Working Group.  The IESG contact persons are Jeffrey Schiller and
Marcus Leech.

Technical Summary
 
This document defines a MIME encapsulation for the OpenPGP Message
Format. It is an update of RFC2015 taking into account lessons learned
during the deployment of RFC2015 based systems. Security protocols
provide a unique challenge for MIME based systems. Specifically it
must be ensured that the binary representation of a message is not
altered by a MIME aware gateway. Modification, if present will always
break any provided digital signatures. Yet the obvious mechanism to
ensure this in MIME is to encode the message in such a fashion that it
is not human readable. This document defines how to best protect a
message from unwanted modification while at the same time managing to
keep the actual message format human readable.

Working Group Summary

The working group came to consensus on this document.

Protocol Quality

Jeffrey I. Schiller reviewed this protocol for the IETF.

Date: Thu, 19 Jul 2001 13:35:09 -0700
To: Thomas Roessler <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: [today] New draft for IANA considerations change
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

At 11:29 AM +0200 7/19/01, Thomas Roessler wrote:
>I'll submit a version with the following IANA considerations section 
>at 1900 GMT, today.  Please raise any objections NOW.
>
>Changes:
>
>- asc and sig are given as extensions for application/pgp-signature
>- no Macintosh file type is given for application/pgp-keys
>
>This version is based on a conversation with Werner Koch.  I have 
>received no further feed-back from NAI.

We'll let the Mac stuff go.  The files are self-describing.  Mac 
implementers are just going to have to figure it out from the content 
of the files.  The file types are parameters on the MIME labels.
But the file types are a local issue, not something for over the 
wire, anyway....

I compared -07 and -08.  Changes are fine.
- -- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------

Date: Thu, 19 Jul 2001 11:29:12 +0200
From: Thomas Roessler <[email-masked]>
To: "openPGP e-Mail (E-Mail)" <[email-masked]>, John W Noerenberg II <[email-masked]>
Subject: [today] New draft for IANA considerations change
Mail-Followup-To: "openPGP e-Mail (E-Mail)" <[email-masked]>, John W Noerenberg II <[email-masked]>
Sender: [email-masked]

--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'll submit a version with the following IANA considerations section=20
at 1900 GMT, today.  Please raise any objections NOW.

Changes:

- asc and sig are given as extensions for application/pgp-signature
- no Macintosh file type is given for application/pgp-keys

This version is based on a conversation with Werner Koch.  I have=20
received no further feed-back from NAI.

>9.  IANA Considerations
>
>   This document defines three media types: "application/pgp-encrypted",
>   "application/pgp-signature" and "application/pgp-keys". The following
>   sections specify the IANA registrations for these types.
>
>9.1.  Registration of the application/pgp-encrypted media type
>
>   MIME media type name: application
>   MIME subtype name: pgp-encrypted
>   Required parameters: none
>   Optional parameters: none
>
>   Encoding considerations:
>
>      Currently this media type always consists of a single 7bit text
>      string.
>
>   Security considerations:
>
>      See Section 8 and RFC 2440 Section 13.
>
>   Interoperability considerations: none
>
>   Published specification:
>
>      This document.
>
>   Additional information:
>
>      Magic number(s): none
>      File extension(s): none
>      Macintosh File Type Code(s): none
>
>   Person & email address to contact for further information:
>
>      Michael Elkins
>      Email: [email-masked]
>
>   Intended usage: common
>
>   Author/Change controller:
>
>      Michael Elkins
>      Email: [email-masked]
>
>
>9.2.  Registration of the application/pgp-signature media type
>
>   MIME media type name: application
>   MIME subtype name: pgp-signature
>   Required parameters: none
>   Optional parameters: none
>
>   Encoding considerations:
>
>      The content of this media type always consists of 7bit text.
>
>   Security considerations:
>
>      See Section 8 and RFC 2440 Section 13.
>
>   Interoperability considerations: none
>
>   Published specification:
>
>      RFC 2440 and this document.
>
>   Additional information:
>
>      Magic number(s): none
>      File extension(s): asc, sig
>      Macintosh File Type Code(s): pgDS
>
>   Person & email address to contact for further information:
>
>      Michael Elkins
>      Email: [email-masked]
>
>   Intended usage: common
>
>   Author/Change controller:
>
>      Michael Elkins
>      Email: [email-masked]
>
>
>9.3.  Registration of the application/pgp-keys media type
>
>   MIME media type name: application
>   MIME subtype name: pgp-keys
>   Required parameters: none
>   Optional parameters: none
>
>   Encoding considerations:
>
>      The content of this media type always consists of 7bit text.
>
>   Security considerations:
>
>      See Section 8 and RFC 2440 Section 13.
>
>   Interoperability considerations: none
>
>   Published specification:
>
>      RFC 2440 and this document.
>
>   Additional information:
>
>      Magic number(s): none
>      File extension(s): asc
>      Macintosh File Type Code(s): none
>
>   Person & email address to contact for further information:
>
>      Michael Elkins
>      Email: [email-masked]
>
>   Intended usage: common
>
>   Author/Change controller:
>
>      Michael Elkins
>      Email: [email-masked]
>

--=20

--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature
Content-Disposition: inline

--fUYQa+Pmc3FrFX/N--

Date: Wed, 18 Jul 2001 21:33:53 +0200
From: Thomas Roessler <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: Will Price <[email-masked]>, Werner Koch <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.
Mail-Followup-To: Florian Weimer <[email-masked]>, Will Price <[email-masked]>, Werner Koch <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

On 2001-07-18 18:52:00 +0200, Florian Weimer wrote:

>>Or should I just drop extensions and Mac file types?

>I would do so for the detached signature.  I don't think there is
>enough time to check all the interoperability issues.

>For the public key ring file, I would rather drop the requirement that
>the content is 7bit ASCII-armored and mention that the extensions
>.pkr, .pgp, .pkr and .asc are common.

Well, changing content-transfer-encoding requirements after WG last 
call (and in a way which breaks old software's expectations) doesn't 
look like the best idea since the invention of sliced bread to me.

But anyway, if NAI isn't interested in finding a reasonable solution 
for this stuff, I'll just leave it out.

To: Will Price <[email-masked]>
Cc: Werner Koch <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.
From: Florian Weimer <[email-masked]>
Date: 18 Jul 2001 18:52:00 +0200
Lines: 24
Sender: [email-masked]

Thomas Roessler <[email-masked]> writes:

> So what change do you suggest?  Should I replace the extension in 9.2
> by ".sig", or list ".asc" and ".sig"?  (I also note that PGP 2.6 and
> PGP 5.0i generate ".asc" for ASCII-armored detached signatures on my
> Linux machine; gnupg generates ".sig".)
> 
> And what file type and extension am I supposed to put in there for
> ascii-armored public keys? ".asc" and "TEXT"?  ".pkr" and "pgPR"? None
> of these seem to make terribly much sense to me.
> 
> Or should I just drop extensions and Mac file types?

I would do so for the detached signature.  I don't think there is
enough time to check all the interoperability issues.

For the public key ring file, I would rather drop the requirement that
the content is 7bit ASCII-armored and mention that the extensions
.pkr, .pgp, .pkr and .asc are common.

Date: Wed, 18 Jul 2001 13:48:19 +0200
From: Ingo Luetkebohle <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Attribute certificates
Organization: Maybe when I grow up
Sender: [email-masked]

--+g7M9IMkV8truYOl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 18, 2001 at 08:17:57AM +0200, Werner Koch wrote:
> 2440bis has one.  Basically you append "@mydomain" to the name and
> make sure that you have control over that domain.=20

Well, I meant a little more with 'interoperability', namely, to enable
others to implement my notations and to implement notations specified
by others. Is there some means to exchange information necessary for
that?

otherwise, thanks for the tips on how I can prevent stepping on other
software's toes :)

--=20
	Ingo Luetkebohle / [email-masked] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--+g7M9IMkV8truYOl
Content-Type: application/pgp-signature
Content-Disposition: inline

--+g7M9IMkV8truYOl--

Date: Tue, 17 Jul 2001 23:19:24 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Attribute certificates
Cc: [email-masked]
Sender: [email-masked]

If you use the notation data for an attribute cert, be sure and
set the critical flag.  That should be a hint to software that it
is not a regular certification signature.  Software is supposed to
ignore sigs that have critical subpackets which it doesn't understand.

Hal

Date: Tue, 17 Jul 2001 23:49:42 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Attribute certificates
Sender: [email-masked]

At 8:17 AM +0200 7/18/01, Werner Koch wrote:
>On Tue, 17 Jul 2001 10:34:21 +0200, Ingo Luetkebohle said:
>
>> Is there any kind of 'official' registration or publishing process for
>> notation data to enable interoperability?
>
>2440bis has one.  Basically you append "@mydomain" to the name and
>make sure that you have control over that domain.
>

Another informal alternative would be to use something similar to the Java
naming scheme. If you prefixed your attributes with : de.pages.blank@ingo,
you'd probably never run into trouble.

	Jon

To: [email-masked]
Subject: Re: Attribute certificates
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 18 Jul 2001 08:17:57 +0200
Lines: 12
Sender: [email-masked]

On Tue, 17 Jul 2001 10:34:21 +0200, Ingo Luetkebohle said:

> Is there any kind of 'official' registration or publishing process for
> notation data to enable interoperability?

2440bis has one.  Basically you append "@mydomain" to the name and
make sure that you have control over that domain. 

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

Date: Tue, 17 Jul 2001 23:42:55 -0400
To: "Bryan Morris" <[email-masked]>, [email-masked]
From: Robert Guerra <[email-masked]>
Subject: Re: Need PGP to automatically encrypt files via a script from our web based applicat
Sender: [email-masked]

bryan:

last time I checked on google, I spotted a few apache/php scripts 
using gnupg to do just the thing you want.

if you find anything, let me know..as i to am looking for something similair

regards

Robert

At 3:25 AM -0400 2001/7/18, Bryan Morris wrote:
>Hello,
>
>We have a web-based software application.
>
>On occasion, we need to transfer confidential data from our client's 
>remote site to our development office.
>
>Is there a way we can install PGP (command line or windows version) 
>and write a script to automatically encrypt the files with our 
>public key and send those files to our tech support staff?  The 
>client would click a button from the browser application and the 
>script would run.
>
>If so, can anyone tell me where I can find the technical details to do this?
>Also reference or URL is appreciated.
>
>Thanks,
>
>Bryan
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

-- 
Progress, far from consisting in change, depends on retentiveness.
Those who cannot remember the past are condemned to repeat it.
"The Life of Reason," 1906, George Santayana (1863-1952)
--
Robert Guerra <[email-masked]>
PGP Keys <http://pgp.greatvideo.com/keys/rguerra/>

From: "Bryan Morris" <[email-masked]>
To: [email-masked]
Subject: Need PGP to automatically encrypt files via a script from our web based applicat
Date: Wed, 18 Jul 2001 03:25:05 
Sender: [email-masked]

Hello,

We have a web-based software application.

On occasion, we need to transfer confidential data from our client's remote 
site to our development office.

Is there a way we can install PGP (command line or windows version) and 
write a script to automatically encrypt the files with our public key and 
send those files to our tech support staff?  The client would click a button 
from the browser application and the script would run.

If so, can anyone tell me where I can find the technical details to do this?
Also reference or URL is appreciated.

Thanks,

Bryan

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

From: "Allan Pratt" <[email-masked]>
To: [email-masked]
Subject: [email-masked]
Date: Wed, 18 Jul 2001 03:22:34 
Sender: [email-masked]

[email-masked]

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Date: Tue, 17 Jul 2001 10:34:21 +0200
From: Ingo Luetkebohle <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Attribute certificates
Organization: Maybe when I grow up
Sender: [email-masked]

--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 16, 2001 at 04:10:54PM -0700, Jon Callas wrote:
> Yes. The Standalone Signatures and Notation signature subpackets are
> designed precisely to set up the sort of arbitrary associations that you'=
re
> looking for. But also, notations can be used other signatures to put in
> information like group membership and so on.

Ah, I had wondered about the notation data but wasn't sure. Thanks for
clarifiying that.

Is there any kind of 'official' registration or publishing process for
notation data to enable interoperability?

Regards
=20
--=20
	Ingo Luetkebohle / [email-masked] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature
Content-Disposition: inline

--9jxsPFA5p3P2qPhR--

Date: Wed, 18 Jul 2001 00:10:48 +0200
From: Thomas Roessler <[email-masked]>
To: Will Price <[email-masked]>, Werner Koch <[email-masked]>
Cc: Florian Weimer <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.
Mail-Followup-To: Will Price <[email-masked]>, Werner Koch <[email-masked]>, Florian Weimer <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

So what change do you suggest? =20

Should I replace the extension in 9.2 by ".sig", or list ".asc" and=20
".sig"?  (I also note that PGP 2.6 and PGP 5.0i generate ".asc" for=20
ASCII-armored detached signatures on my Linux machine; gnupg=20
generates ".sig".)

And what file type and extension am I supposed to put in there for=20
ascii-armored public keys? ".asc" and "TEXT"?  ".pkr" and "pgPR"?=20
None of these seem to make terribly much sense to me.

Or should I just drop extensions and Mac file types?

PLEASE ADVISE ASAP.  THE FINAL DRAFT MUST BE IN THE I-D REPOSITORIES=20
WITHIN LESS THAN 48 HOURS.

--=20

On 2001-07-17 13:10:23 -0700, Will Price wrote:
>Date: Tue, 17 Jul 2001 13:10:23 -0700
>From: Will Price <[email-masked]>
>Reply-To: [email-masked]
>X-Mailer: Mozilla 4.75 (Macintosh; U; PPC)
>To: Florian Weimer <[email-masked]>
>Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
>Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macin=
tosh=20
> file type codes.
>
>
>The "pgDS" file type is a Detached Signature. The correct file extension
>for a detached signature is ".sig". These are ASCII files. They do *not*
>use the ".asc" extension.
>
>The "pgPR" file type is a Public Keyring file. The correct file extension
>for a Public Keyring file is ".pkr". These are always binary files.
>
>".asc" files sometimes contain keys, and sometimes contain encrypted
>and/or signed data -- always in ASCII format. These files have no special
>Macintosh file type. The file type for these is the standard "TEXT".
>
>The "pgRR" file type is a Secret Keyring file. The correct file extension
>for a Secret Keyring file is ".skr". These are always binary files.
>
>The "pgEF" file type is a PGP encrypted and/or signed file. The correct
>file extension for such a file is ".pgp". These are usually binary files,
>but not always.
>
>
>
>Florian Weimer wrote:
>>=20
>> Excerpt from the current OpenPGP/MIME draft:
>>=20
>> | 9.2.  Registration of the application/pgp-signature media type
>>=20
>> |    Encoding considerations:
>> |
>> |       The content of this media type always consists of 7bit text.
>>=20
>> |    Additional information:
>> |
>> |       Magic number(s): none
>> |       File extension(s): asc
>> |       Macintosh File Type Code(s): pgDS
>>=20
>> | 9.3.  Registration of the application/pgp-keys media type
>>=20
>> |    Encoding considerations:
>> |
>> |       The content of this media type always consists of 7bit text.
>>=20
>> |    Additional information:
>> |
>> |       Magic number(s): none
>> |       File extension(s): asc
>> |       Macintosh File Type Code(s): pgPR
>>=20
>> Doesn't Macintosh PGP (and perhaps other programs as well) store
>> binary data in pgDS/pgPR files as well?  That's why I don't think the
>> MIME types and Macintosh file types are equivalent.
>
>
>--=20
>
>Will Price, Director of Engineering
>PGP Security, Inc.
>a division of Network Associates, Inc.
>

--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature
Content-Disposition: inline

--k+w/mQv8wyuph6w0--

Date: Tue, 17 Jul 2001 14:01:30 -0700
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: Derek Atkins <[email-masked]>
CC: Florian Weimer <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh    file type codes.
Sender: [email-masked]

Actually, we don't care. We just happen to generate them as ASCII.

Derek Atkins wrote:
> 
> Will Price <[email-masked]> writes:
> 
> > The "pgDS" file type is a Detached Signature. The correct file extension
> > for a detached signature is ".sig". These are ASCII files. They do *not*
> > use the ".asc" extension.
> 
> So you can't have a binary detached signature?  It must be ASCII?
> 
> -derek
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        [email-masked]                        PGP key available

-- 

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

To: Derek Atkins <[email-masked]>
Cc: [email-masked], "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh   file type codes.
From: Florian Weimer <[email-masked]>
Date: 17 Jul 2001 22:58:31 +0200
Lines: 19
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:

> Will Price <[email-masked]> writes:
> 
> > The "pgDS" file type is a Detached Signature. The correct file extension
> > for a detached signature is ".sig". These are ASCII files. They do *not*
> > use the ".asc" extension.
> 
> So you can't have a binary detached signature?

AFAIK, PGP 2.6.x can create such signatures, and there's nothing in
the OpenPGP standard which outlaws them, quite the contrary.  Probably
you only can't process them on the Mac due to lack of a proper file
type. :-/

To: [email-masked]
Cc: Florian Weimer <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh   file type codes.
From: Derek Atkins <[email-masked]>
Date: 17 Jul 2001 16:44:15 -0400
Lines: 14
Sender: [email-masked]

Will Price <[email-masked]> writes:

> The "pgDS" file type is a Detached Signature. The correct file extension
> for a detached signature is ".sig". These are ASCII files. They do *not*
> use the ".asc" extension.

So you can't have a binary detached signature?  It must be ASCII?

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Tue, 17 Jul 2001 13:10:23 -0700
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: Florian Weimer <[email-masked]>
CC: "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh  file type codes.
Sender: [email-masked]

The "pgDS" file type is a Detached Signature. The correct file extension
for a detached signature is ".sig". These are ASCII files. They do *not*
use the ".asc" extension.

The "pgPR" file type is a Public Keyring file. The correct file extension
for a Public Keyring file is ".pkr". These are always binary files.

".asc" files sometimes contain keys, and sometimes contain encrypted
and/or signed data -- always in ASCII format. These files have no special
Macintosh file type. The file type for these is the standard "TEXT".

The "pgRR" file type is a Secret Keyring file. The correct file extension
for a Secret Keyring file is ".skr". These are always binary files.

The "pgEF" file type is a PGP encrypted and/or signed file. The correct
file extension for such a file is ".pgp". These are usually binary files,
but not always.

Florian Weimer wrote:
> 
> Excerpt from the current OpenPGP/MIME draft:
> 
> | 9.2.  Registration of the application/pgp-signature media type
> 
> |    Encoding considerations:
> |
> |       The content of this media type always consists of 7bit text.
> 
> |    Additional information:
> |
> |       Magic number(s): none
> |       File extension(s): asc
> |       Macintosh File Type Code(s): pgDS
> 
> | 9.3.  Registration of the application/pgp-keys media type
> 
> |    Encoding considerations:
> |
> |       The content of this media type always consists of 7bit text.
> 
> |    Additional information:
> |
> |       Magic number(s): none
> |       File extension(s): asc
> |       Macintosh File Type Code(s): pgPR
> 
> Doesn't Macintosh PGP (and perhaps other programs as well) store
> binary data in pgDS/pgPR files as well?  That's why I don't think the
> MIME types and Macintosh file types are equivalent.

-- 

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

To: "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.
From: Florian Weimer <[email-masked]>
Date: 17 Jul 2001 21:19:59 +0200
Lines: 34
Sender: [email-masked]

Excerpt from the current OpenPGP/MIME draft:

| 9.2.  Registration of the application/pgp-signature media type

|    Encoding considerations:
|
|       The content of this media type always consists of 7bit text.

|    Additional information:
|
|       Magic number(s): none
|       File extension(s): asc
|       Macintosh File Type Code(s): pgDS

| 9.3.  Registration of the application/pgp-keys media type

|    Encoding considerations:
|
|       The content of this media type always consists of 7bit text.

|    Additional information:
|
|       Magic number(s): none
|       File extension(s): asc
|       Macintosh File Type Code(s): pgPR

Doesn't Macintosh PGP (and perhaps other programs as well) store
binary data in pgDS/pgPR files as well?  That's why I don't think the
MIME types and Macintosh file types are equivalent.

Date: Mon, 16 Jul 2001 16:10:54 -0700
To: Ingo Luetkebohle <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Attribute certificates
Sender: [email-masked]

At 12:20 AM +0200 7/17/01, Ingo Luetkebohle wrote:
>Hi,
>
>has there been discussion of specifing something like X.509 attribute
>certificates for PGP? Basically, an attribute certificate is a
>certification that some arbitrary association holds for the key
>owner. E.g., it could be used to certify membership to some group or
>to express other information about the key owner.
>

Yes. The Standalone Signatures and Notation signature subpackets are
designed precisely to set up the sort of arbitrary associations that you're
looking for. But also, notations can be used other signatures to put in
information like group membership and so on.

	Jon

Date: Tue, 17 Jul 2001 00:20:03 +0200
From: Ingo Luetkebohle <[email-masked]>
To: [email-masked]
Subject: Attribute certificates
Organization: Maybe when I grow up
Sender: [email-masked]

--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

has there been discussion of specifing something like X.509 attribute
certificates for PGP? Basically, an attribute certificate is a
certification that some arbitrary association holds for the key
owner. E.g., it could be used to certify membership to some group or
to express other information about the key owner.

Regards=20

--=20
	Ingo Luetkebohle / [email-masked] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
Content-Disposition: inline

--sdtB3X0nJg68CQEu--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-mime-07.txt
Date: Fri, 06 Jul 2001 06:49:59 -0400
Sender: [email-masked]

--NextPart

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

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-07.txt
	Pages		: 15
	Date		: 05-Jul-01
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[email-masked]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

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

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

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-mime-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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 6 Jul 2001 00:25:55 +0200
From: Thomas Roessler <[email-masked]>
To: John W Noerenberg II <[email-masked]>
Cc: Marshall Clow <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.
Mail-Followup-To: John W Noerenberg II <[email-masked]>, Marshall Clow <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

On 2001-07-05 15:06:41 -0700, John W Noerenberg II wrote:

>>(Macintosh) PGP Encrypted file:		pgEF

>This needs to be added to 9.1.  

No.

>It's possible that a UA will write the encrypted data to a file. 
>It's helpful for Mac files to have the right type.  It certainly 
>isn't harmful to the document to add it.

The encrypted data is in an application/octet-stream body part 
(which is the second part of a multipart/encrypted), not in 
application/pgp-encrypted.  application/pgp-encrypted is the first 
part of a multipart/encrypted, which is supposed to hold meta 
information about the encrypted data.  With PGP/MIME, that's just a 
dummy, containing the character string "Version: 1".

See also section 4, and the example on page 5 of the draft.

Date: Thu, 5 Jul 2001 15:06:41 -0700
To: Thomas Roessler <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions,  Macintosh file type codes.
Cc: Marshall Clow <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

At 9:53 AM -0700 7/3/01, Marshall Clow wrote:
>(Macintosh) PGP Encrypted file:		pgEF

This needs to be added to 9.1.  It's possible that a UA will write 
the encrypted data to a file.  It's helpful for Mac files to have the 
right type.  It certainly isn't harmful to the document to add it.

-- 
john noerenberg
[email-masked]
   --------------------------------------------------------------------
   There is no illusion more dangerous than the belief that the
   progress of science is predictable.
   -- Freeman Dyson, "Six Cautionary Tales for Scientists", 1988
   --------------------------------------------------------------------

Date: Tue, 3 Jul 2001 09:53:39 -0700
To: Thomas Roessler <[email-masked]>
From: Marshall Clow <[email-masked]>
Subject: Re: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

>IESG requests that we add a IANA consideration section to the PGP/MIME text.
>
>This section should also contain indications of file extensions and Macintosh file type codes to be used for the media types we define.
>
>I suppose that we should list none for application/pgp-encrypted, and .asc as the file extension for application/pgp-signature and application/pgp-keys.  However, what are the Macintosh File Type Codes to be used for the latter two media types?

PGP 7.03 uses the following types:

PGP Encrypted file:		pgEF
Detached Signature:		pgDS
Public Key Files:		pgPR
Secret Key Files:		pgRR
-- 
-- Marshall

Marshall Clow     Idio Software   <mailto:[email-masked]>

Warning: Objects in calendar are closer than they appear.

Date: Tue, 3 Jul 2001 11:44:48 +0200
From: Thomas Roessler <[email-masked]>
To: "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.
Mail-Followup-To: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

IESG requests that we add a IANA consideration section to the 
PGP/MIME text.

This section should also contain indications of file extensions and 
Macintosh file type codes to be used for the media types we define.

I suppose that we should list none for application/pgp-encrypted, 
and .asc as the file extension for application/pgp-signature and 
application/pgp-keys.  However, what are the Macintosh File Type 
Codes to be used for the latter two media types?

Please reply ASAP.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: separation of signed and encrypted pgp mesages into signed pgp messages
Date: Mon, 2 Jul 2001 16:35:51 -0400
Sender: [email-masked]

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

>There was a recent paper,
> > <http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>
> describing a flaw in the sign and encrypt function of Open PGP.

Despite the gratuitously over-hyped title, the paper does make it
clear that the "flaw" is one of understanding.  In particular, it is
necessary to understand *what* is being signed, and for many systems,
it is *only* the message body.  Unsigned material, including headers
(sender, receiver, and what-not), can be changed.  If you want clear
identities (or other context) in the signed text, you need to put
them there.

Yes, some products gloss over the details.  PGP, for instance,
labels the function "Encrypt&Sign" when it really works in the
other order.

> the author assumes that is is possible for the recipient
> to strip off the encryption from a signed and encrypted pgp message, 
> leaving only a verified signed message,
> and that the ability to do this is ensured in the Open PGP Standard

Yes.  This *can* be a desirable feature.  If you don't like it, you
can: (a) include enough context in the signed material; and/or, (b)
manually encrypt, then sign (but as the paper points out, doing so
without context offers only marginally different protection).  I'd be
more than happy for end-user agents to offer to do one or both.  I
would not be happy with the specification mandating particular agent
behavior -- it does not appear to mandate sign-then-encrypt now.

> {afaik} this can be done in pgp only when both the receiver and sender are
> using RSA keys, 

No.  The specification does not tie packet composition to the type
of key used.  [But in practice: newer PGP versions that support DSA/DH
keys also support one-pass signatures, so they may have extra packets,
but this has no bearing on the "problem" at hand.]

Date: Mon, 2 Jul 2001 11:15:39 -0700
To: "vedaal" <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: separation of signed and encrypted pgp mesages into signed pgp messages
Sender: [email-masked]

At 1:15 PM -0400 7/2/01, vedaal wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>There was a recent paper,
><http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>
>describing a flaw in the sign and encrypt function of Open PGP.
>

Well, while this is an interesting paper, it doesn't really describe a
cryptographic problem at all, it describes a semantic problem.

The problems he outlines don't require encryption, they all work equally
well with clear-signed messages, and as someone else pointed out probably
work just fine with unsigned messages for the simple reason that if someone
sends bare text, people tend to believe its authenticity.

>the author assumes that is is possible for the recipient
>to strip off the encryption from a signed and encrypted pgp message,
>leaving only a verified signed message,
>and that the ability to do this is ensured in the Open PGP Standard
>
>{afaik} this can be done in pgp only when both the receiver and sender are
>using RSA keys,
>

OpenPGP describes that a message is signed, and then the bundle of the
plaintext and signature are encrypted. So yes, it's certainly possible for
someone to decrypt a message and you then have in your hands a signed
message. It does *not* matter what key type it is; the packet formats are
the same no matter what the key type.

>{can be done only from 2.6.x with the simple one step command:
> pgp -da(filename)
>which will leave an armored signed message in text form, with a signature
>that verifies in any version of pgp
>
>cannot be done in later command line versions of pgp, as the -d command,
>will just decrypt, and not leave a signature,
>the -b command will do the same.}
>
>the people at sci.crypt seem to feel that as long as the program conforms
>to pgp standards, such a separation is *do-able* for any key type, even if
>a
>custom program must be written to do this.
>
>
>does anyone know of any way that this separation can be done for a message
>signed and encrypted with a DH/dss key,
>with pgp, gpg or any other program, and, is it, in-fact, guaranteed by the
>Open PGP Standard, that it 'must' be so?
>

Take a look at the RFC. Look in particular at Section 10.2. There's nothing
in there that specifies what the key type is.

	Jon

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: separation of signed and encrypted pgp mesages into signed pgp messages
Date: Mon, 2 Jul 2001 13:15:27 -0400
Sender: [email-masked]

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

There was a recent paper,
<http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>
describing a flaw in the sign and encrypt function of Open PGP.

the author assumes that is is possible for the recipient
to strip off the encryption from a signed and encrypted pgp message, 
leaving only a verified signed message,
and that the ability to do this is ensured in the Open PGP Standard

{afaik} this can be done in pgp only when both the receiver and sender are
using RSA keys, 

{can be done only from 2.6.x with the simple one step command: 
 pgp -da(filename)
which will leave an armored signed message in text form, with a signature
that verifies in any version of pgp

cannot be done in later command line versions of pgp, as the -d command,
will just decrypt, and not leave a signature,   
the -b command will do the same.}

the people at sci.crypt seem to feel that as long as the program conforms
to pgp standards, such a separation is *do-able* for any key type, even if
a
custom program must be written to do this.

does anyone know of any way that this separation can be done for a message 
signed and encrypted with a DH/dss key, 
with pgp, gpg or any other program, and, is it, in-fact, guaranteed by the 
Open PGP Standard, that it 'must' be so?

vedaal

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.263 / Virus Database: 135 - Release Date: 6/22/01