pem-dev
[Top] [All Lists]

Re: Key selectors (Was: Re: unpublished public keys )

1994-12-23 14:48:00
May I remind you that PGP dealt with the MIME integration issue over a
year ago? (And here we are, two years later and counting, and we
haven't done squat.) True, the way PGP did it is now seen to be an
error, and there's a move on to use the security multipart mechanisms
we're discussing with PGP, but the old way does work and people do use
it.

So why dont we just adopt it?

It works and users apparently use it. What more do we need?

End of Issue.

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.

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.

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.

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

I don't want to comment now on the redundancy of the micalg part.. 

-derek

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