On Wed, 28 Dec 1994 jefft(_at_)netcom(_dot_)com wrote:
1. Do you want the key selector because it hides the public key so
that people cannot factor the modulus?
Nope. Key selectors are for selecting keys. Whether they help stop
factoring attacks or not is a happy consequence of some forms of key
selectors. It's up to the user to decide whether they want to have this
extra level of security through obscurity.
2. If yes, would simply using a digest of the public key suffice (as
Burt Kaliski of RSADSI proposes, see included message below)?
Not applicable, but I wouldn't object to using a digest.
3. Do you want the key selector because it wards off traffic analysis
so that the identities of the originators and recipients can be
concealed?
Nope. Traffic analysis is not something I care too much about, but that's
just me. In any case, one needs to go to a lot of trouble to conceal the
identities of originators and recipients. PEM is not enough. Anonymous
remailers, multiple key pairs, etc are also necessary.
4. If yes, should we formally propose this as a design goal for
MIME/PEM and spend the time necessary to address all the issues
implied by such a goal (versus adding this service later, etc.)?
Not applicable. I don't think this is something that PEM can adequately
address on its own. Leave it to another document to say "to avoid traffic
analysis, use PEM in the following way: ...".
After reading the discussion over the last couple of weeks, I'm happy if
the public key or some digest of it is used as a key selector and
everything else is moved out into application/pemkey-data. I'm also happy
if everything stays as is. One suggestion I do have (which is probably
too late for inclusion) is to allow application/pemkey-data to be in the
same multipart as the application/pem-signature or application/pem-keys
content types. e.g.
Content-Type: multipart/signed; boundary=xyz; .....
--xyz
Content-Type: text/plain
blah, blah, blah
--xyz
Content-Type: application/pem-signature
SIGNATURE INFORMATION
--xyz
Content-Type: application/pemkey-data
KEY INFORMATION
--xyz--
The alternative would be to have an outer multipart/mixed with an inner
multipart/signed. Since I expect that most MIME-PEM implementations will
always include the key data by default, my version is a little less
jarring on the non-MIME user's eyes. But I won't hold up the MIME-PEM
process pushing for this. It's not a show-stopper for me, just a last
minute suggestion and probably not in keeping with the system-neutral
approach used in multipart/signed and multipart/encrypted.
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"