[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: processing of "speculative" key ids: MAY -> SHOULD¦MUST
thanks for the response. sorry for the delayed response. my comments
> i think the burden of proof of uniqueness of usefulness is not
> on me ;-)
wolfgang> If you want to have added something into a standard, you should
wolfgang> be aware that this addition causes at least additional work for
wolfgang> implementors (and may have other "side effects" as well).
wolfgang> Therefore, I consider it only fair that the "suggestor" has to
wolfgang> point out all the wonderful advantages that his/her suggestion
wolfgang> brings with it.
i agree w/ that mostly, i think it is very reasonable. i hope that
you would accept "some of the wonderful advantages" as i don't presume
to be able to foresee all of the consequences of ideas ;-)
i would hope that after some initial discussion, the working group
could enumerate a more comprehensive list of advantages and
wolfgang> So, in some way, the burden of proof of usefulness _is_ on you.
i agree that usefulness should be shown -- i will try, but after reaching a
certain point, i hope the burden is not all mine!
[ but i didn't make any claim about burden of usefulness -- what i
was referring to was burden of proof of uniqueness of a particular use:
wolfgang> Speculative key ids are only helpful when used together with
wolfgang> nym-servers (as otherwise the mail headers would permit the
wolfgang> traffic analysis that the sender wants to avoid).
sorry if that seemed picky, but uniqueness is one of those things to
be picky about, i think ]
i would like to reiterate one of my earlier points:
> also, openpgp doesn't have to be used only for mail.
to enumerate a couple of non-mail-related ideas:
-a pam module which uses pgp key pairs in a challenge-and-response
authentication scheme. iirc, ssh2 has something similar (that explicitly
mentions openpgp) in section 4.6 of
-encrypted irc sessions -- an automated participant (bot) w/ a key
pair and public keys of potential participants hands out public-key-encrypted
session keys to those who can authenticate (using openpgp
challenge-and-response). participants send out messages encrypted
using the session key. to read a message, each participant decrypts
using the session key. session keys are regenerated periodically
and retrieved by clients who can authenticate.
i suspect one of the main potential uses of speculative key ids is
supporting anonymity and prevention of traffic analysis. if that is
indeed the case, combined w/ the fact that openpgp can be used in a
number of different domains (mail and non-mail) i hope that people
would be supportive (or perhaps considerate?) of speculative key ids.
perhaps you were already aware of these ideas and i was reading too
much into your words...my apologies if so.
wolfgang> But it may well be that all the other members of this mailing
wolfgang> list were already aware of the advantage of speculative key ids
wolfgang> that you mentioned, and I am the only one who had not seen this.
wolfgang> If this is the case, then shame on me! :-(
if i may be so bold, i would not be surprised if a few people hadn't
thought it through yet, but the fact that speculative key ids exist in
the rfc suggests that the idea seemed useful enough to some -- sorry i
don't know the history of speculative ids, perhaps someone can
but back to the original point, i agree that MUST is a bad idea for
speculative ids. i propose that at least there be some mentioning of
potential interoperability issues regarding the use of speculative key
ids for certain types of situations (to be elaborated on?). i also
think it would be worth recommending that processing support be
available -- but that it does not have to be used.
is this a reasonable suggestion?