-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIB4DCCAXUCBQJBAAI3MA0GCSqGSIb3DQEBAgUAMGMxCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEyMDAGA1UECxMpVW5hZmZp
bGlhdGVkIFVzZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwNTE2MDAw
MDAwWhcNOTYwNTE2MjM1OTU5WjB6MQswCQYDVQQGEwJVUzEOMAwGA1UEERMFMjIw
NzAxETAPBgNVBAgTCFZpcmdpbmlhMRAwDgYDVQQHEwdIZXJuZG9uMR4wHAYDVQQJ
FBUyMDEgRWxkZW4gU3RyZWV0IKYxNzMxFjAUBgNVBAMTDUFtYW5kYSBXYWxrZXIw
XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsYTQHrGTWxpS22owJLNVkmBNxGW6Z8TK
5Qdsg9co9J8uyHOuqEIHIxOIDsVA7X/bsYVXxvitmc5PYKp2RuWj+QIDAQABMA0G
CSqGSIb3DQEBAgUAA1YAIR3BS02rsquq3dY6sGWcieXW3HtChMtsReRhDdY/nGPz
rIUYuWt087c4T4afrsG9FbouJOkAsR/5SkLI9UpXonDIUskdl4/JlRKpyLaX07RK
mUyTSR==
Issuer-Certificate:
MIIB/jCCAWsCBQIFAAABMA0GCSqGSIb3DQEBAgUAMFwxCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjErMCkGA1UECxMiQ29tbWVy
Y2lhbCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05MzA1MDEwMDAwMDBaFw05
ODA0MzAyMzU5NTlaMGMxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBT
ZWN1cml0eSwgSW5jLjEyMDAGA1UECxMpVW5hZmZpbGlhdGVkIFVzZXIgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwcDANBgkqhkiG9w0BAQEFAANfADBcAlUxe5CmA5dy
igi8ZWJpGJdctHi5wvnIVcG9aupi7+ym5hDyFtVLEeJy5U31xIHz/RSoRJvy0RiY
LtSUOZWWlHol6aEzss1lEknAZNX1aluc+ia7NuvxAgMBAAEwDQYJKoZIhvcNAQEC
BQADfgBe/pia8Oo46rbZlEZE5S0JDsrqWRS5v2ia0D55lJHQqr5vLY0pJy4sSbcp
0r7ZihMMEEO4o8Mu5ZjM8F1ZfEXPy0mWaHPoVxvb13sXgo17Q9m2U58hvjI72U0m
nyB7fXhsjlnFSm8PN0zaTx6RRv8dxvyC42V2mPz6xciQcw==
MIC-Info: RSA-MD5,RSA,
PvLhobGYnUcOW99e0lnG+Y+Z+fURujj3oxd7b77hcuYSRAh0r0u5JJGzmTL32JCF
chog0HJhpHXqf5LDNM2htQ==
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! :-)
Just as a matter of curiosity, why do you think that a bare key is
more useful for encryption than for signature? I have tended to think
that there was a very strong duality between the two concepts, and
almost always what was required for one was required for the other.
I should think that the need to be reasonably sure exactly who it was
that you were confiding your deep dark secrets to would be very similar
to the need to verify your correspondent's bone fides before believe
him. Why then would a bare key be more useful for encryption?
There are cases where I explicitly want anonymous but secure
communication.
There are cases where I have obtained someone's public key through some
other channel, and don't want arbitrary observers to be able to garner
any additional information about what entity that key is associated
with.
Basically, certification does not necessarily happen in-band, and in
such cases all you need or want is the key.
Well, here is something that is at least concrete. Rhys Whetherley observed
something similar:
As you say, it is necessary to verify who you are sending to. But that is
done _before_ the encryption takes place. Once you've verified it,
there's no need to send a full certificate to the recipient. They know
who they are and have a secure copy of their own key (one hopes anyway).
However, they might have multiple keys which necessitates sending some
kind of key selector or bare public key to tell the recipient which of
their many keys was used to encrypt the message.
I agree with both of you, so please pardon me while I think aloud for a bit...
It certainly shouldn't be necessary, and in many cases may not be desirable, to
send the originator's certificate along with the message, especially if the
certificate contains all of the details of your name, rank, and serial number
in the clear. John Gilmore made that point rather persuasively over three years
ago, and turned my thinking around. Likewise, if you are communicating with
someone via some kind of a blind forwarding mechanism, you don't want the
identity of the recipient to be disclosed, either. (In this case I assume that
you would double encrypt the message to your recipient, so that only the
forwarder would know who to send the inner message to. But the forwarder could
also reencrypt the message, including your orignal certificate, so only the
forwarder would know who was communicating with him or her.) Yet I suppose that
it is desirable that both the originator's and recipient's certificates be
identified somwhow, if only to avoid having to try multiple certificates to see
which one works.
We have the Persona type of certificates, of course, but I guess that it could
be argued that this is an undesirable bit of extra process to use for the
purpose you described.
Let's see. Suppose that the recipient has a dozen keys that he or she uses at
various times. Is it too much effort to simply try them all? After all, any
other approach is going to require sending SOME kind of an identifier, and
sooner or later someone would be able to put two and two together. And by the
way, a dozen is probably rather extravagent. Except for some of the idiots on
the news groups that conceal their identities under multiple names to avoid
being caught by someone's kill file, it is hard to imagine a need for more than
two or three, depending on the number of roles that someone has. (Unless they
are really paranoid, and use a key of the day concept.)
A full message digest of the key would probably be too revealing, since it
would map directly to the certificate/key itself. I wouldn't hink that you
would want to use a bare key, for the same reason -- too much correlation from
message to message. But what if we were to use just a one or two byte hash of
the key, or maybe just an index into the user's key space. In fact, if the
recipient had only one CA/issuer of certificate/keys, we could just use the
sequence number of the key itself for this purpose.
Unless the recipient uses a different key for each different mailbox address, I
don't yet see how the key selector mechanism really solves this problem. I
suppose you could put something in the private name space to say "this is from
the friend you met last night -- use your key number 3 and my key number 17."
But did I miss something? All this seems like a lot of trouble for two
consiprators to go to -- they might as well agree on a secret triple-DES key
and be done with it, or just talk in the parking lot while they are secretly
exchanging disks.
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.
Just as you are champing at the bit to release a PEM/MIME
implementation, I'm working hard to develop a system for issuing
and managing certificates within an organization.
OK... how do non-certificate-based applications impact this effort? I
would think that such a system would be simply unconcerned with
alternative applications. It might not even support them; it's a
separate animal.
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.
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.
The more I work with X.500 the more I am convinced that this is a highly >>
desirable way to accomplish this.
Agreed. No one's arguing (that I have noticed) that X.509 isn't a good
way to represent certificates. It's even an international standard.
The issue is that certificates themselves are not always necessary or
desirable.
Well, that's progress, anyway. I think the issue comes down to ecoinomy of
mechanism, even if the mechanism selected is somewhat complex. I sympathize
with Rhys -- he shouldn't have to be recoding all of this stuff. but if you
agree that certificates need to be supported for forward and backward
compatibility, adding additional mechanisms would seem to just make matters
worse.
In addition, we need to manage, archive, revoke,
etc. these certificates within an organization. None of this has
anything at all to do with MIME, and little to do with the integration
of PEM and MIME, or MIME and e-mail, or even PEM, MIME, and an X
.500 directory user agent.
Agreed :).
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 also understand your frustration with the process. You apparently have a MIME
product and would like to further its differentiation in the market by
supporting PEM features, and that is certainly laudable. 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.
I seem to recall a discussion very much like this, just before Christmas last
year. I hope that we won't be in the same position next year!
Amanda Walker
InterCon Systems Corporation
-----END PRIVACY-ENHANCED MESSAGE-----
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820
PS. The astute reader (or one with an operational PEM) will notice that the
message digest of the above message doesn't match the signature, and correctly
conclude that Amada was not the sender, regardless of what the certificate
says. But it does make it look "official," doesn't it? :-)