ietf-openpgp
[Top] [All Lists]

Re: processing of "speculative" key ids: MAY -> SHOULD¦MUST

2000-01-21 05:31:04
sen_ml(_at_)eccosys(_dot_)com wrote on Fri, 21 Jan 2000 01:16:05 +0900:

let's not get into a discussion of nym servers here though.  (i hope
you didn't mean "anonymous remailer" when you mentioned "nym-server",
because to me those two are not the same.)

Sorry for my sloppy usage of nomenclature: What I meant was
remailing via mixmaster chaining (see e.g.
"http://www.obscura.com/~loki/remailer/mixmaster-faq.html";).

speculative key ids can be useful in the context of a mailing list
that has its own keypair plus the public keys of all recipients.  it
can prevent people from finding out who all of the subscribers are via
the interception of a single message ...

Clever idea! I had not thought about this type of usage.

I admit that in this context, speculative key ids would gain us
something that could not easily be done otherwise.

i think the burden of proof of uniqueness of usefulness is not
on me ;-)

If you want to have added something into a standard, you should
be aware that this addition causes at least additional work for
implementors (and may have other "side effects" as well).
Therefore, I consider it only fair that the "suggestor" has to
point out all the wonderful advantages that his/her suggestion
brings with it.

So, in some way, the burden of proof of usefulness _is_ on you.
But it may well be that all the other members of this mailing
list were already aware of the advantage of speculative key ids
that you mentioned, and I am the only one who had not seen this.
If this is the case, then shame on me! :-(

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: wolfgang(_at_)redtenbacher(_dot_)de
---------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>