Ned,
Well, go ahead, to be amazed. The PEM spec (1421) is very
explicit about the context in which is is intended to be used. It
does not provided for multiple signatures applied to a single message.
The context of the comment I made to Steve Crocker was a more general
one than email, the domain of PEM. I was objecting the the idea that
a simple signature mechanism, applied to a single object, should be
used in a fashion that does not make explicit what the signer is
trying to convey with the signature. For PEM, the signature facility
was a means of providing authenticity and integrity, and a basis for
non-repudiation, as stated up front in 1421. The sematics of these
security services in the email context were expected to be obvious,
i.e., they are merely secure versions of the services that many people
implicitly ascribe to email, and that are reasonable to ascribe to
email in a benign envrionment.
In a more general context of signed objects, it is quite
reasonable to use multiple signatures to convey more complex meanings,
e.g., serial vs. parallel signatues for approval of purchase
requisitions. However, I think it also reasonable to have explicit
constructs that differentiate between serial and parallel signatures
and that allow the signer, or the creator of the object, to express
the meaning to be associated with different sorts of signatures. For
example, in a fiduciary context, different signatures (numbers of
roles) are required for different levels of expenditure or different
clases of expenditure. If one wants automated validation of digitally
signed financial authorizations, then the rules for what constitutes an
acceptable signature for different expenditures must be explicit and,
I think, syntactically derivable. Thus my strong reaction to Steve
Crocker's suggestion that the interpretation of multiple signatures is
soley up to the recipient.
Now, let's get back to the question of what 1421 does and does
not say. The primary intent of the nesting provision cited in section
4.4 is to facilitate enclosing signed PEM messages that are being
forwarded. Forwarding of PEM-signed messages is used as the
motivation for this facility throughout section 4.4 and the text
reinforces this idea through its reference to the use of the nesting
conventions established RFC 934 for forwarding of mail. The text in
4.4 makes the point that the encapsulation and nesting provisions are
intended to allow for forwarding PEM-signed mail and optionally adding
annotations to this forwarded mail. Although one could,
syntactically, use this facility to add multiple layers of signature
to a single content, the text in 4.4 in no way suggests this as an
appropriate use of the nesting feature.
I think the other points you make about multiple signatures in
PEM are similarly delat with. For example, 4.1.2.1 describes the
processing steps in preparing a PEM message. While you are correct
in noting the ability to enclose multiple PEM-protected objects in
parallel in the processing, the text also makes clear what the intent
is for providing this facility, i.e., forwarding of messages and
optionally adding annotations.
The differences we seem to see in reading 1421 are, I suspect,
at the root of the concerns I have over the current MIME-PEM spec, and
may be a contributor to the general flavor of the arguments that have
been going on for the last month. (First let me note that I am still
750 message behind and am reading mail out of order, so I am not
completely conversant with all of the debate that has ensued.) The
1421-1424 series of PEM specs tries hard to explain its scope of
applicability, the problems it is attempting to solve, and how it goes
about solving those problems. Thus the syntax and processing of PEM
is not the only focus of 1421, even though it is what "counts" for an
implementor. 1422 emphasizes the motivation behind the certification
hierarchy design, why certain constraints are imposed, why processing
is performed in a specific manner.
The PEM-MIME spec is a "delta" spec. It states its primary
purpose as providing the same security functionality as established in
1421, but extending this functionaity to the MIME environment.
However, it then notes that other changes have been made, to provide
increased functionality. It does not provide a description of a new
scope (other than extention to MIME) for the new/changed security
functionality. Rather, the flavor of the spec is one that provides
building blocks that can be used to provide security services in a
variety of ways, as seen fit by users and implementors. In this
regard, the PEM-MIME spec is very MIME-like.
I am concerned with this approach to developng ANY spec, not
just PEM-MIME. Without a fairly explicit statement of the problem
being solved, I have a hard time evaluating whether the proposed
mechanisms (syntax and processing) are the best way to solve the
problem, or even if they do solve the problem. In this case, I worry
that the problem space has been made much larger and not well
articulated. There is more of a sense of this spec being a part of a
larger system, but the larger system is not completely designed.
Some of the arguments that are taking place may be the result
of different participants viewing this spec as a solution to different
problems. If we don't agree on the set of problems being solved, then
we probably can't agree on the solutions.
So, where do we go from here? I have heard arguments that we
must advance this spec as is, or with very minor changes, because the
community desparately needs secure MIME email and if we don't have a
spec, then ad hoc solutions will be forthcoming. This is certainly a
valid concern, but I observe that there have been competing, secure
email products (e.g., ones that use RSA and DES) from several vendors
for a few years. Will vendors be willing to make changes to their
products if we find the need to make significant changes to this spec
later? Will that be easier than migrating from some other spec?
The greatest concern might be that we have competing,
non-interoperable secure email widely deployed, or that the
competition between such systems prevents widespread deployment. But,
there are other competitors out there (or out there soon) that are
credible and may achieve widespread deployment. For example, MSP will
be in shrink-wrapped offerings from Lotus and Microsoft and other
vendors, because they are catering to the U.S. Defense Message System.
The initial DMS MSP implementaions will be on top of X.400, but the
protocol is designed for use above SMTP as well, and it is designed to
be able to be encapsulated by MIME and to carry a MIME message, as
well as operating in the X.400 environment. (MSP is not a general
purpose MIME security spec, in the flavor of the current specs we
have. MSP is focused on email applications, with forwarding and
annotation etc., but with a well-defined model of the problem being
solved.) MSP is as algorithm independent as the PEM-MIME spec and it
has features related to mailing list support, return receipts,
etc. that are not in any of the PEM specs. So, it too represents a
vialble candidate in the secure email arena, and it has the advantage
of being well-integrated into commercial email packages. It also is
avialble in a C-code implementation for the asking, though one is well
advised to use that implementation as a starting point for a
production-quality implementation.
PGP has become popular for some subset of the Internet
population. If there is to be a PGP-MIME spec soon, we should ask how
the PEM-MIME spec will differ, where there is overlap, and whether two
different communities are being served by these specs. If some of the
features introduced into the current spec are an attempt to provide
PGP-like features, maybe we don't need them if there will be a
PGP-MIME spec as well.
It may make sense to have parallel, incompatible secure email
protocols if the communities served are distinct, but to have
non-interoperable protocols for overlapping communities doesn't seem
so promising. (Ultimately, this is an issue for the security area
director to resolve.)
To get a better idea of what the WG feeling is on this topic,
I plan to hold a non-binding, electronic referendum. No, you won't
have to use secure email to "vote." I'll let you know what the two
mailbox names will be. One will be to vote for going with what we've
got and one to vote for doing more work. Votes in the latter category
should contain specific recommendations of what needs to be changed in
the current spec to make it acceptable. If the vote suggests that
there is a general concensus to move ahead with the current spec, then
we can do that. If there is a strong, well-articulated opposition
with focused comments, then we will need to resolve those comments
before progressing the document. I hope to have the email boxes in
place by 1-1-95.
Steve