Quoting my signature would have been cuter if you'd remembered to
unquote the -----END PRIVACY-ENHANCED MESSAGE----- line as well :).
Amanda, I don't know where you have been lurking until recently, but it is
refreshing to see someone who is relatively new to this discussion put
forward some articulate, well thought-out positions, even if I may not
agree! :-)
Well, I've been reading pem-dev for a long time off and on. I've decided
it's more worthwhile to contribute (even if it telegraphs information to
competing vendors) than to sit by and let Ned and Jim take all the heat :).
Bottom line -- I'm not yet convinced of the need to adopt addition mechanisms,
when what we have available now can solve the same problem and be more
compatible with existing standards and implementations.
I am, to be truthful, not too concerned with the key selector issue one way
or another. All of the databases in our products are free-form anyway, so
whatever ends up in the spec regarding key management is likely to be a
small speed bump for us at best, if at all. That being said, I wouldn't
mind dropping the key selector as an explicit identifier and using either
of the alternative ideas that have been mentioned: self-signed certificates
or bare public keys in the Originator-ID field. I'm not going to hold
things up by arguing the issue either way, though. To me, this is a minor
detail, although I understand that it may not be to others. This is why
I haven't been addressing this particular aspect of the proposal directly.
I am concerned that users will receive messages from other users, some in
certificate format, some using a bare key, others using some private naming
convention, and they expect that all of these different schemes will be
supported. I agree that it could be done, but don't feel that it is worth the
expense.
Well, if you have the key, you can decrypt the message. All that is affected
is your ability to verify the signature (which is itself addressed if you
can look up certificates by key in your key database, which is a good idea
anyway).
If you really feel that all of this is necessary, I would prefer that you make
PEM/MIME directly compatible with PGP. At least then there would only be two
models that had to be supported, instead of potentially five different forms
of
key selectors plus PGP.
It is my understanding that PEM/MIME is in fact designed to accomodate PGP.
Certainly MIC-CLEAR messages can be signed with PGP as well as PEM, given
the definition of the appropriate body parts. In fact, I don't quite see
why multipart/signed has to be restricted to two parts--I can imagine
someone wanting to sign something in both PEM and PGP formats simultaneously.
Finally, I agree with John Lowrey regarding the need for the "services" that
classical PEM undertook to provide. Without understanding what policy we are
trying to support, providing mechanisms is just bit-twiddling. It provides a
facade of security that will lull the unaware, perhaps to his doom.
I disagree. We cannot begin to think about policy until the mechanism is
in place. Policy is inherently subjective. The cryptographic operations
are not in dispute; how to denote signatures and encrypted body parts in
MIME is not in dispute. There are the only things that MIME/PEM addresses.
Discussions of policy, however important they are, and however much they
fall under this working group's charter, are a separate issue in my view.
It is clear we need to have some general discussions concerning policy.
No argument. I just don't want to hold up MIME/PEM while we debate them.
I want to pass MIME/PEM up the chain and *then* debate them :).
but if the PEM working
group had worked hard to solve the underlying infrastructure problmes, instead
of collectively going to sleep while trying to solve an even harder problem, I
think we would have been further ahead.
No argument at all. But I don't get to implement things as if that
infastructure existed (well, not and expect people to buy my stuff :)).
There are many things I wish had happened with PEM. Timely startup of
the IPRA, something like RSAREF three years earlier, residential PCAs like
the RFCs discuss, and so on. But those things didn't happen. We can't
design systems for the ideal world--if we expect what we produce to be
a standard in fact as well as in name, we must be pragmatic, or this
effort risks becoming a purely academic exercise.
Amanda Walker
InterCon Systems Corporation