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.
I'm sorry Steve, but you are just plain wrong about this. By allowing multiple
signed objects in the same message, classic PEM opens the door to having
multiple copies of the same object signed by different people in the same
message. It is cumbersome to use classic PEM this way, I agree, but that
doesn't change the fact that such usage is totally legal in classic PEM.
If you wanted to close this door you would have had to prohibit having more
than one signed object in a message. You didn't do this, and thus left the door
open both to this usage as well as nested structures where you have one
signature wrapped around another. None of the semantics associated with any of
these perfectly legitimate uses are specified in any way, shape, or form in any
of the existing RFCs. You suggest some possible uses of these things, but leave
the door wide open (I cannot image prose that would open it any wider) to all
sorts of other applications.
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.
You're wrong about this as well. The present MIME/PEM specification does NOT
presently provide a means by which more than one signature can be applied to
the same object at the same level. Such usage would require the definition of a
new MIME content type to carry the multiple signatures, and thus an additional
document would be needed to provide this definition.
As such, the present MIME/PEM specification provides EXACTLY THE SAME services
that classic PEM provides in this area. It is true that extending MIME/PEM to
provide new services is much simpler than it would be to do in classic PEM, but
the fact remains that no such extension has yet been specified. If there's
actually a need to specify additional semantics in association with such
definitions (which I doubt -- I agree with Steve Crocker and Amanda Walker
here), that can be addressed once the specification of such an extension
actually exists.
Again I assert that MIME/PEM actually cleans up a lot of loose ends in classic
PEM in this area. If you seriously think that the fact that you can leverage
such services off of MIME/PEM necessitates a detailed discussion of their
implications at this time, the inescapable conclusion is that classic PEM is
even more flawed than MIME/PEM and must therefore be withdrawn immediately
until this major bug (as you seem to see it) can be fixed, either by
specifying the semantics fully or else by adding restrictive prose to
explicitly preclude the use of classic PEM in this fashion.
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.
These are precisely the services that MIME/PEM presently provides as well.
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.
Precisly right. And they are equally obvious in MIME/PEM as well.
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.
This is all very nice, but you have yet to explain why, since these facilities
are in fact provided by classic PEM, why you failed to either prohibit them or
describe their semantics there.
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.
Such facilities can in fact be built very easily within the MIME/PEM framework
-- a heck of a lot more easily than in the classic PEM framework. So why don't
we get the base specifications finished and out the door so work can start on
defining such things?
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.
It doesn't suggest that it is inappropriate either. My reading is that this use
of classic PEM is entirely legal. If it isn't legal you should have said so.
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.
Steve, if you want a specification not to allow certain types of use, you state
that it doesn't allow those types of use. Specifications are by definition
restrictive of illegal uses, not automatically inclusive of all legal uses.
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.
I have a much simpler view. I think you are applying a double standard to these
documents, and are effectively establishing overly stringent criteria for
MIME/PEM that the classic PEM work doesn't come close to meeting either.
Moreover, you are basing this demand on the incorrect premise that the MIME/PEM
work currently provides more functionality in this area when in fact it does
nothing of the sort.
I also disagree that this is the core of what we've been discussing for the
past month. We've discussed lots of unrelated things in the past month, and the
only substantive issue I see on the to-do list is that of key selectors.
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 see as more like classic PEM than MIME in this regard. In MIME, for example,
when we define collections of objects we also specify what semantics are
associated with such collections. (We were not content to stick with a single
sort of "mixed bag" collection that most mail systems use.) In MIME we even
group atomic objects in ways that serve to indicate the semantics of the object
even if you don't understand the specific format the object is in (these are
the primary MIME types). In MIME the concept of messages and the objects they
contain are kept separate, and we go to a lot of effort to maintain this
distinction.
Classic PEM, on the other hand, defines two basic services
(authentication/integrity and encrypton) and specifically defines means for
combining the services in fairly arbitrary ways. (The fact that combining the
services is combersome and fairly unpleasant doesn't mean anything in this
context.) The specifications then talk about some of the more rudimentary
applications such combined services have. And then they stop. Nothing is said
about more complex combinations. They are obviously there, and they are equally
obviously not prohibitied.
MIME/PEM is just like classic PEM in this regard.
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.
If you really think this is so then you have no choice but to call for the
withdrawl of the classic PEM specifications.
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.
We need to get the infrastructure in place so that different solutions can be
developed. Without the infrastructure in place we can do nothing and nobody's
needs can be met.
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?
Well, the Working Group reached consensus on the specifications at the San Jose
meeting. I was there and I saw it. We are now in working group last call. As I
said above, the only substantive issue I know of is that of key selectors (and
it happens to be one issue I don't much care about). Once this is settled the
specifications should go forward with whatever changes are needed in the
key selector area.
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.
Where are the specifications for all this MIME stuff? I doubt very much that
any trivial injection of such services into MIME will work properly.
(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.
Where do you get this C implementation?
You seem to be arguing that the entire PEM effort is irrelevant here and that
we might as well all give up and do something else. If you really feel this
way, I think you owe it to the Working Group to step down as chair ASAP.
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.
As I have stated several times in the past, I don't think the possibility of
MIME/PGP mitigates the necessary of redoing PEM in any way. Without the
MIME/PEM changes PEM is simply not a viable protocol.
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.)
Actually, the services of PEM and PGP are not incompatible at all if the
security multipart approach is used.
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."
How could we?
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.
We've already effectively taken this vote at least twice, most recently in San
Jose. Frankly, I find it more than a little offensive that you think it is
necessary to repeat this exercise again.
As I've stated in previous messages, this is the end of the road for me in any
case. If the vote "passes" (whatever that means) and MIME/PEM moves forward
as-is I'll probably support it. If it doesn't pass I see no reason to continue
this pointless dance any longer, and I'll be looking for other solutions to
this problem. (Note that this may well mean taking the present MIME/PEM
specifications and implementing them regardless of what this Working Group does
with them either now or in the future.)
Ned