Subject: [urgent] PGP/MIME IANA considerations: file extensions, Macintosh file type codes.

From: Thomas Roessler <[email-masked]>
Date: Tue, 3 Jul 2001 11:44:48 +0200

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.

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

---

From: Marshall Clow <[email-masked]>
Date: Tue, 3 Jul 2001 09:53:39 -0700

>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.

---

From: John W Noerenberg II <[email-masked]>
Date: Thu, 5 Jul 2001 15:06:41 -0700

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
   --------------------------------------------------------------------

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 6 Jul 2001 00:25:55 +0200

>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.

---

From: Florian Weimer <[email-masked]>
Date: 17 Jul 2001 21:19:59 +0200

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.

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

---

From: Will Price <[email-masked]>
Date: Tue, 17 Jul 2001 13:10:23 -0700

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.

-- 

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

---

From: Derek Atkins <[email-masked]>
Date: 17 Jul 2001 16:44:15 -0400

> 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

---

From: Florian Weimer <[email-masked]>
Date: 17 Jul 2001 22:58:31 +0200

Derek Atkins <[email-masked]> writes:

> 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. :-/

---

From: Will Price <[email-masked]>
Date: Tue, 17 Jul 2001 14:01:30 -0700

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

--

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 18 Jul 2001 00:10:48 +0200

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?

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

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, Macintosh 
> file type codes.
>
>

---

From: Florian Weimer <[email-masked]>
Date: 18 Jul 2001 18:52:00 +0200

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".)
> 
> ascii-armored public keys? ".asc" and "TEXT"?  ".pkr" and "pgPR"? None
> of these seem to make terribly much sense to me.
> 

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.

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 18 Jul 2001 21:33:53 +0200

>.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.