There have been several discussions on these lists about the
integration of PEM and MIME. Here is a proposal for adding
privacy-enhancement to MIME that does not impact either the PEM or
MIME effort.
PKCS message formats should be utilized to add privacy-enhancement of
mail messages in a MIME environment.
Why ? You ask...
Here are some reasons:
Binary message format.
Message standards.
Compatability with PEM.
Ease of implementation.
Added functionality.
Let me expand on these...
Binary message format
PKCS specifies a message format based on ASN.1 Basic Encoding Rules.
This is an 8 bit message format. One of the "powerful" features built
into MIME is the ability to handle 8-bit mail messages. There is a
useful encoding scheme to encode binary into 7-bit ASCII for today's
less efficient MTPs :-), however an 8 bit standard for security will
likely grow well. In addition, the use of ASN.1-based security will
gateway easily into X.400 messaging applications.
Message standards.
A non-trivial amount of the work in developing privacy-enhancement for
mail has gone into the formatting and parsing requirements for
messaging. While a methodical integration with MIME would still
require some specifications to be written, the actual signed and
enveloped message formats are already well-defined in the PKCS. No
new work would be necessary to define and document needed message
syntax. These standards are in the public domain. They are available
via anonymous ftp from "rsa.com". There has been much interest in
industry and by standards-making committees domestic and
internationally to adopt these standards. This has many positive
connotations for interoperability in the future.
Compatability with PEM
PKCS is NOT in competition with PEM. In fact there are many
compatabilities between the two. The PKCS were developed with PEM
compatability as a primary goal. PKCS can be thought of as PEM with
BER encoding. A full description of PKCS-PEM compatability can be
found in the PKCS documents. Here's a few highlights:
- The PEM standards specify the same algorithm "object identifiers"
as PKCS for symmetric and assymetric encryption. These object ids
point to critical details for performing the cryptographic methods in
a way that guarantees interoperability. (Coincidence, I think not !)
- The certificates are interchangable. That's right, one certificate
for both uses. This means, of course, that when all of the smoke
clears around the current PEM effort, the certificate strategy will be
usable in a PEM or PKCS environment.
- PEM can be converted to PKCS without any cryptographic operations,
just some encoding and reformatting. This is extremely helpful when
making gateways. Certain modes of PKCS can be converted to PEM in the
same manner.
Let me stress this point again, PKCS is NOT competition to PEM. PEM
is the best fit with the current RFC822 mail environment. If
anything, there is incredible pressure to release PEM as-is.
Integration of PKCS and MIME would allow the PEM effort to move
forward without reservation.
Ease of implementation
All things being relative, PKCS are fairly easy to implement. How
much of my PEM development effort can I reuse ? Quite a bit; in fact
everything but the message formatting/parsing code. Rumor has it
that there are toolkits that do the PKCS messages both here and
abroad. The major building blocks for making PKCS are; low level
crypto code (same as PEM), cert. chaining/checking code (same as
PEM), ASN BER/DER engine for formatting and parsing (fun, fun, fun).
Added functionality
This is my favorite part. There are some extra features that the
PKCS allow. Features that are not part of the current PEM effort.
Like:
- The PKCS allow for detached signatures. This allows signature
information to be kept in a separate body part of a message. This
effectively makes it easy to create a signature for any type of body
part without modifying the part being signed. A sort of MIC-CLEAR
for any type of information. Detached signatures also facilitate
easy implementation of multiple signers of a single message. This is
useful for counter-signatures and trusted time-stamping, etc.
- Room for growth. The PKCS allow for signed and unsigned attributes
in signed messages. This makes extending the specification very
straightforward. Some sample uses for attributes; "time-of-signing",
comments, message-ids, file names, spending limits. The PKCS, like
PEM, are a framework into which new algorithms can be added. Say,
for instance, that some large administrative organization adopts a
new public key algorithm because RSA is too efficient...
- The PKCS allow for an enveloped-only message. This would eliminate
much of the need for those pesky PERSONA certs since no signature is
required to communicate privately and anonymously.
In summary, if there is significant interest in this approach we will
explore the MIME integration issues more closely. Again, the PKCS are
available via anonymous ftp from "rsa.com".
I have tried to focus on the positive technical aspects of this
proposal, I hope that comments and criticism are equally
constructive, however all comments and criticism are welcome.
Cheers,
Steve Dusse