[Top] [All Lists]


1992-06-05 21:58:08
Marhsall, Mark, Steve Dusse, Dave Crocker, et al.,

I just became aware of the discussion that's been taking place on this
list.  As Marshall said, several of us did indeed discuss this several
days ago and we didn't quite reach closure.  I've reviewed the thread
starting with Steve Dusse's (spock) Jun 2, 12:12 p.m. message through
Jim Galvin's Jun 3 11:24 a.m. message, so I'll chime in.

First, I don't think we're all that far from closure.  The timing is
painfully awkward, however, and *nothing* is ever real easy.  Even if
the technical content can be sorted out within an hour, the process of
communciating and convincing a sufficient number of people and the
process of tweaking the software and specs takes a long time.  In the
present instance, John Linn, the author of 1113 (the basic pem spec),
was not online during the discussion Marshall referred to.  His mailer
is now up and I've shipped him the relevant messages.  I also had a
long talk with him last evening.  Also, Steve Kent, the PEM WG chair,
tends to be rather busy and probably hasn't had time to jump into
this.  (The fact that he's on the IAB is probably more relevant to
other people's perceptions than to the way he conducts the WG.)

Having said all that, let me assert strongly that I think merging PEM
and MIME is an excellent idea, and I'm all for it.  However, I think
there are a small number of details that need to be visited -- perhaps
just to educate us PEM types -- and it's even possible that there's
some subtlety.  Most of the points have been made.  I think Marshall
expressed them most comprehensively.  Let me go over them as I see

1. Where to add PEM?

The distinction between authenticated messages and encrypted messages
seems important.  I spent several hours one evening a couple of weeks
ago examining MIME and figuring out where I'd insert PEM.  I came up
with two results, and the distinction is exactly as has been said:
When I encipher, I want to encipher everything within the scope I
choose, and it's not acceptable to have an unauthorized agent see
whatever substructure there may be.  On the other hand, if I have only
protected the integrity and sender identification, then it's
reasonable for an agent to see through the substructure.  (There's a
different argument that says the ability to extract the substructure
without checking the signature will undermine the security of the
entire system.  There's merit to this argument, but I think this can
be a marketplace issue.  ((I expect strong disagreement from some;
strong agreement from others.  Don't be bashful.)))

That distinction led me to propose that we use application/pem for
encipherment and that we add signed/sealed messages elsewhere in the
tree.  We communicated this idea and that's what Dave Crocker and
others stated in this thread.

2. What kind of thing is PEM?

Ok, so we've settled on application/pem as the right place for
enciphered objects.  What about bodies which are just signed and
sealed?  Should (signed/sealed) body be a subtype of message?  A
subtype of text?  A new CTE?

I'm less clear about this, but it seems silly to add PEM to MIME
without also making it work for all of the base types, viz audio,
image, video, text and application.

        Comment: I find it important to distinguish between the five
        terminal ("base") types and the two recrusive types, viz
        message and multipart.

        Comment: If we define application/pem, then application just
        became a recursive type, albeit outside of the scope of MIME.

If we choose to hang PEM on type message, then the PEM headers might
fit into the header part of the message and the body would then be of
whatever type it needed to be.  I don't fully see all of the
implications, but I'm comfortable with this.

Alternatively, many people will focus on the idea that message body
within the currently defined PEM consists of an alternating series of
enhanced and unenhanced parts.  This corresponds to MIME's multipart,
and the natural conclusion is that each of the components corresponds
to a MIME type of text, not message.

This distinction may be a bit hard to see at first, so I'll restate
it, reversing the order just to confuse you a bit.

Second proposal: "PEM" is a subtype of a terminal type, particularly
text.  A message with multiple parts to it, some of which are enhanced
and some of which are not, would have the following (example) structure:

    body of any type
    body of any type

First proposal: "PEM" is a subtype of message.  A message with multiple
parts to it, some of which are enhanced and some of which are not
enhanced, would have the structure:

    body of any type
      header + body of any type
    body of any type
      header + body of any type

The simpler proposal seems more natural at first sight, but I suspect
it's actually better to hang pem off of type message.

3. What about CTE?

I understand the MIME requirement that CTEs not exist for the
recursive types.  However, some of the data we put into a PEM message
is inherently binary, viz the keys, and has to be encoded somehow.  We
use a radix 64 encoding, the same as MIME.  We also have a MIC_CLEAR
option which keeps the text in the clear but encodes the certificates.
How should all this be handled in MIME?

One possibility is to define a new type of object specifically to
handle the PEM headers -- certificates, message keys, etc.  If we do
this, we may have to revisit the placement question above, or perhaps
it modifies the description without making a real change.

However, I don't sense much interest in defining a new type just for
PEM headers.

        Comment: MIME could have defined a type for MIME headers and
        not defined two recursive types.  What is now a "message"
        would be just a multipart with exactly two parts, one of which
        is a header and the other is whatever you wish.  This is not a
        quibble; the current MIME approach is much more
        straightforward.  I'm just putting the issue of PEM headers in

So that leaves us with a problem.  Where do we encode the messy PEM
headers?  Do we always encode them in base64 as part of PEM processing
and present them to MIME as if they originated in ASCII?  That will
work, but it means that if a MIME message is encoded in base64, the
PEM headers will be re-encoded in base64 again.  Hmmm... Isn't that
what the no recursive encoding rule is designed to prevent?

I don't have a clear answer for this.

4. Decoration and transformation

This is a PEM-specific issue, or maybe it isn't.

An important aspect of the MIME design is the anticipation of agents
which partially process the mail and pass along the results.  We could
use something similar for PEM.  In cases where I can trust the agent,
I might want signatures verified and possibly messages deciphered
before I interact with the message.  For those cases, I'd like the
results of the processing to be added as annotations to the message.
(All of this presupposes I have a trusted path between the agent and
my own machine, and that arbitrary non-MIME messages cannot arrive
looking like annotated de-enhanced (gad! what a word) messages.  Let's
stipulate we're indeed making those assumptions and we're limiting
this dicussion to those cases.  I still think this is important.)

What this leads to is the notion of a MIME-to-MIME tranformation.  That
is, I want to define the PEM process as one that takes a MIME message
and transforms it into another MIME message.  On the way in, this
transformation de-enchances the messages by checking the signature and
deciphering the text.  On the way out, this transformation takes an
annotated message, adds a signature and (optionally) enciphers it.
And if the means for annotating the message are simple enough, then
this will be the method of choice for marking which sections are to
enciphered selectively.

Anyone in the MIME community think about things along this line?

5. Marking boundaries

Finally, there's a concern in the PEM community that the optional
omission of delimiters makes it impossible to figrue out how much text
is included in the signature checking process.  This is a small nit,
but needs to be nailed.


So where does this leave us?  We at TIS are now testing the version of
PEM we (think!) we'd like to release for beta testing.  Copies should
be in the hands of the favored few within two weeks.  Not a good time
for change.  Nonetheless, my board has a diagram on it right this
minute -- check the timestamp and note that I'm leaving town later
today for 2-1/2 weeks; not much else is getting this kind of priority!
-- that shows something like:

   [text, delimited de/pre-enhanced text, text, ...]


   [text, appln/pem, text, appln/pem, ...]  <----> interface to MIME


   [text, pem-body, text, pem-body, ...]    <----> interface to
                                                   current PEM specs

The idea of this being to have it both ways within our implementation
and to phase out the non-MIME representation if it becomes OBE.

Ok folks, that's the way I see it.  If we can tie up these nits,
perhaps just be understanding each other's model one notch more
deeply, and if we agree on a satisfactory merger that makes it obvious
how to apply PEM to all of the MIME base types, then we should move
forward quickly and embed PEM squarely within MIME.  And even if we
can't solve *all* of these problems, if the basic framework is clear
and we can solve just the addition of PEM to MIME text, then I agree
we should do it.  But we're alo under enormous pressure to get PEM out
the door *just the way it is*.  Remember, in addition to the message
processing aspects of PEM, there is a major certificate hierarchy we
have to get into place, and the longer we delay PEM, the longer it
will take to get that started.  So we either have to make these
decisions instantenously, or we have to merge PEM into MIME on the
fly.  I think the latter is inevitable, but unlike other on-the-fly
transitions, I don't think this one will be very hard.  (Famous last
words :-)


 |  Steve Crocker                      | Voice: 301-854-6889           |
 |  Trusted Information Systems        | FAX:   301-854-5363           |
 |  3060 Washington Road               |-------------------------------|
 |  Glenwood, MD  21738                | Internet: crocker(_at_)tis(_dot_)com   

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