[ If this message specifically addressed to you, please read. I know
pem-dev traffic has been exceptionally high recently. Thank you. ]
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.
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.
Steve, I agree completely that we are having trouble settling on
solutions because people won't state what problem it is they want
solved. I have repeatedly been trying to flush the birds out of the
bushes, as it were, to get people to do this.
In anticipation of your referendum (which I hope you get a reasonable
response to) let me be so bold as to include again one of my pleas for
comment (included below).
- Jeff
Included message, subject: key selector survey:
Steve Kent writes:
Still, this does not address the question of whether the
design of a system that facilitates communication without transmission
of certificates should be a goal of PEM. Rhys gave some examples of
why he thought that might be a goal. I'm not convinced that trying to
keep public keys secret is at all an appropriate access control model,
but the WG should decide that. A more likely rationale is an attempt
at prevent traffic analysis, but TA was explicitly reuled out as a
security service for PEM in 1421, so this motivation would represent a
definate change of direction.
Steve, your message conveys the severity of introducing traffic
analysis as a security service. Implementing TA security is not to be
taken lightly, and introducing a key selector only begins to address
the issues.
I would like to make an informal survey so we know what concerns we
are really addressing. I especially ask for response from people who
have been vocal in favor of the key selector: warlord(_at_)mit(_dot_)edu,
rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au, wford(_at_)bnr(_dot_)ca,
williams(_at_)atlas(_dot_)arc(_dot_)nasa(_dot_)gov,
perry(_at_)snark(_dot_)imsi(_dot_)com, vitor(_at_)uminho(_dot_)pt,
galvin(_at_)tis(_dot_)com(_dot_)
1. Do you want the key selector because it hides the public key so
that people cannot factor the modulus?
2. If yes, would simply using a digest of the public key suffice (as
Burt Kaliski of RSADSI proposes, see included message below)?
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?
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.)?
In general, if the answer to #1 is yes, I think we can reach closure
almost immediately. If the answer to #3 is yes, more discussion is
needed.
- Jeff
Included message from Burt about using a digest of the public key:
Which brings us back to the early proposal to identify public keys by
their message digest. The syntax:
<digest algorithm identifier>, <digest of DER-encoded public key>
should work just fine. (It works for all types of key, and the size is
constant.)
-- Burt Kaliski
RSA Laboratories