[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

An Encryption Proposal




I've been considering the question of how closely to follow
RFC2015 (PGP/MIME).

The problem with adhering too closely to RFC2015 is that it
makes life difficult for those users who don't have access to
a PGP/MIME enabled mail client.  Allow me to explain:

One of the features of PGP/MIME is that the message is first
encapsulated in a MIME "envelope" that includes the message
and all of its attachments and that MIME "envelope" is then
encrypted.  The encrypted output is attached as a MIME
attachment to a e-mail message and it is all then sent to the
mail server.  This behavior is generally a good thing, since
it protects all of the e-mail, including any information
about the parts of the message that you could normally get
from looking at the MIME headers.

The downside to this encoding is that, if you don't have a
PGP/MIME e-mail client at the receiving end, you have to
unwrap the attachments from the MIME envelope after the file
is encrypted.  There aren't a lot of good tools to let the
user do that easily, especially if one of the attachments is
Base64 encoded.

The alternative is to simply encode the file by hand and
attach it to an e-mail message and send it.  This might make
for a little more work for a PGP/MIME enabled recipient, but
it lets the PGP/MIME-less user to decrypt the attached file
and get a useable data file.  Also, just about any e-mail
system can attach a PGP encrypted file, but there are fairly
few that do proper PGP/MIME.

So, what I'd like to propose is that, when sending messages
to our business partners and clients, we simply encrypt the
file and attach it to an e-mail message without using
PGP/MIME.  When receiving data, we should make an effort to
accept both the simple encrypted attachments from
non-PGP/MIME clients and PGP/MIME messages.  However,
regardless of how it was received, we should always send the
response back in a non-PGP/MIME encrypted attachment.

Perhaps we can talk about this in the next conference call. 
Or, you can flame me in advance on the listserv. <g>