Uhh, maybe I missed the original message, but I'd like to know how
"PGP dealt with MIME integration"? I think that the original poster
is slightly mistaken. There is an internet draft on PGP-MIME
integration, but all the authors have agreed to let that slide and
work towards a common (multipart/signed, multipart/encrypted) method.
The "original poster", i.e. me, specifically said that there was a draft but
that the approach chosen there had been droped in favor of the multipart
security work. So everything you say here is correct except for your inference
that this wasn't spelled out in the original posting. It was.
Given that goal, I think I should comment on the PEM-MIME draft
(draft-ietf-pem-mime-07.txt) -- having just read it, I have a
statement about it, and then a question (which is probably a simple
question).
I like most of it, but I'm not sure I like the way multipart/encrypted
is done. In particular, I don't like how the DEK information and the
message are separate -- when the message is encrypted, they are
integrated parts, you cannot separate them, so why put them in
separate MIME parts? It's not like MIME can do anything without
decrypting the data first, right? I would think that it would behoove
us to put the KEY DATA and the Encrypted Data in the same mime-part.
Sure, you can put the key information into the encrypted material itself, but
doing so requires that you develop an encapsulation mechanism for it. Then each
different encryption methodology could potentially choose a different one,
which in turn makes things much more complex.
On the other hand, MIME provides a perfectly reasonable framework for
encapsulating such things - multipart. Moreover, every MIME-capable agent
has support in place for this format already. Why not simply leverage off
of this encapsulation facility that is already deployed?
There has been some talk about sending encrypted material with NO DEK
information at all -- you just have to know what the key is. In this case you
could either leave the first part empty or else just use
application/octet-stream and be done with it. After all, why label something as
encrypted when it cannot be decrypted automatically?
The reasoning behind this is related to my goal above. PGP is
inherently a binary message format, and the KEY DATA is part of the
binary message. Separating this from the message would mean putting
some kind of parsing routine between PGP and MIME both on the
encrypting end and the receiving end. It could be done, but it would
be another step that would be required on both ends of the processing.
By not separating the key information and the encrypted message, we
solve this problem without creating any more problems, as far as I can
tell.
You may save some implementation work with your approach, but not that much --
you have to deal with the split for multipart/signed. And you potentially lose
a lot -- the present scheme can readily be extended to allow for sending the
same encrypted material to different users using different security services.
(This does require a common encryption algorithm, but it looks like we may end
up with one with triple-DES.)
Now, for my question: In the draft, I didn't see anything that struct
me as being the equivalent of MIC-ONLY. I would assume that you would
do a MIC-ONLY by using this construct. Am I correct?
Content-Type: multipart/signed; protocol="application/pem-signature";
micalg="rsa-md5"; boundary="Signed Message"
--Signed Message
Content-Transfer-Encoding: radix-64
Content-Type: text/plain
SIGNED-MESSAGE
--Signed Message
Content-Type: application/pem-signature
SIGNATURE INFORMATION
--Signed Message--
Sure, this would work, but it isn't MIC-CLEAR. MIC-CLEAR would be:
Content-Type: multipart/signed; protocol="application/pem-signature";
micalg="rsa-md5"; boundary="Signed Message"
--Signed Message
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
SIGNED MESSAGE
--Signed Message
Content-Type: application/pem-signature
SIGNATURE INFORMATION
--Signed Message--
I don't want to comment now on the redundancy of the micalg part..
Then why bring it up?
Ned