Mark,
I think you're suggesting the introduction of a new type, Binary, for
use in PEM. Let me suggest an alternative.
We've been focused on integration of PEM and MIME in order to make
good use of the infrastructure MIME provides. In particular, MIME
provides a widely accepted way to incorporate multiple types within a
single message, ways to encode the body parts for transmission, and
ways to delineate the boundaries between the parts.
Marshall Rose, Ned Freed and I drafted a spec for integrating PEM and
MIME. It's intended to handle privacy enhancement for any MIME body
part. If this moves along quickly, it could become the dominant form
of PEM, thereby providing an integrated solution. Backward
compatibility with the current PEM specs could be maintained for
however long is necessary.
For this reason, I'd rather avoid adding new, ad hoc, types to PEM and
work within the MIME framework. The first draft of our spec is
draft-ietf-pem-mime-00.txt in the internet-drafts directory. Ned has
written a new draft and I'm going to study it over the next few days.
One goal for this spec is that it should be reasonably clean and
attractive even for non-MIME PEM implementation. That is, if someone
wants just a straight PEM system without necessarily being prepared to
handle MIME in general, the subset of the integrated spec that deals
only with PEM for text should be tolerably close to ideal.
With respect the specific issue you've raised of sending binary
information in a protected fashion, I see this as two separate
problems. First, how is binary information to be tagged, encoded and
delineated, and second how is it to be signed and optionally
encrypted? As I said above, I think the right answer for the second
part is to integrate PEM and MIME and have a common scheme for signing
and encrypting all types of data. That leaves only the first part.
Let me suggest you focus on how best to include within the MIME
framework the kind of binary information you want. It's my
understanding that the MIME folks tend to resist the creation of new
values for Content-Type, and suggest instead the creation of new
subtypes or attributes when need be.
Steve