[ If this message specifically addressed to you, please read. I know
pem-dev traffic has been exceptionally high recently. Thank you. ]
Per your request, although I trimmed the cc list.
1. Do you want the key selector because it hides the public key so
that people cannot factor the modulus?
Yes. In fact, it was included in the design because we were told it had
to be there.
2. If yes, would simply using a digest of the public key suffice (as
Burt Kaliski of RSADSI proposes, see included message below)?
Qualified yes. Burt's proposal has a lot of appeal when combined with
your other proposal to move the naming information to the
application/pemkey-data body part. You may recall that an earlier
version of the current draft specification had just this proposal in it.
The proposal was dropped due to the additional complexity associated
with including an algorithm identifier along side of the hash value.
The complexity isn't major, I agree, but having it is yet one more place
where an originator and recipient may potentially not interoperate.
Before we get into a discussion of how likely this is to occur, we
observed the complexity was unnecessary. (Also, see my response to
Burt's message.)
The principal purpose of the key selector is to distinguish between the
multiple keys of a user. While I agree that the public key itself also
serves this purpose, it has the disadvantage of disclosing the public
key, an undesirable feature.
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?
No.
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.)?
N/A.
Jim