ietf-openpgp
[Top] [All Lists]

Re: Revising RFC 2015

1998-09-10 07:51:32
Message-ID: 
<SIMEON(_dot_)980910085535(_dot_)A(_at_)gallileo(_dot_)esys(_dot_)ca>
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 <kazu(_at_)iijlab(_dot_)net> 
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:Steve(_dot_)Hole(_at_)esys(_dot_)ca  
Phone:403-424-4922

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

<Prev in Thread] Current Thread [Next in Thread>