[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
follow.

> 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
disadvantages.

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

     draft-ietf-secsh-transport-06.txt

  -pgp tickets:

     draft-moscaritolo-mione-pgpticket

  -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
enlighten me?

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?