[OTR-users] Pretty-please standardize OTR signature storage, per OS.

[subharo at hushmail.com]

Hello,

I agree with Greg Grossmeier in his post called "OTR apps using 
keyrings/wallets?", posted Sun Jul 21 00:35:00 EDT 2013:
http://lists.cypherpunks.ca/pipermail/otr-users/2013-
July/002225.html

Greg, I think the problem is even bigger than how you state it.

I've been trying a few different OTR-aware IM clients: Jitsi, 
Pidgin, and Gajim.  Each program is unware of the other's use of 
OTR, and any OTR signatures it's already managing.  Each program 
will gladly generate a unique OTR fingerprint for a given XMPP 
account.  Then when I talk to a contact from each different IM 
client, the contact sees 3 different OTR signatures, which of 
course looks highly suspicious like they're being "attacked" by 
someone else masquerading as me.  This isn't just messy data 
management, it's a downright *security vulnerability false 
positive* waiting to happen.  Newcomers to OTR are going to get 
frustrated over this FAST!  Please don't allow this to scare them 
away.

What if the OTR project had a published *Standard*, saying where 
and how OTR keys should be stored (including filesystem permissions 
that should apply), for every OS where OTR is currently in use (and 
there aren't that many of them).  Then the likes of Jitsi, Pidgin, 
and Gagim could all refer to that one standardized, known folder in 
common (silently creating it if necessary).

GnuPG already does something like this, and *it works*.  On Unix 
systems, for example, Keyrings are stored in ~/.gnupg.  The 
filesystem permissions are such that this folder and files inside 
have no read, write, or executable permissions for those other than 
the user who owns them.  Then frontends such as Enigmail, Seahorse, 
and APG all know to refer to ~/.gnupg.  The end user is not hassled 
to do any "converting" of the keyrings.  It's just a folder, so 
it's also easy to back up and restore.  It's simple, elegant and 
effective.  Why not follow suit?

So in summary, Greg, I agree with you, however I think the OTR 
project should publish a Standard, and not write another piece of 
software to perform "conversions".  Based upon this Standard, it 
should then be up to each IM client supporting OTR to conform to 
the Standard, and not keep re-inventing the wheel for themselves.

When Samuel Carlisle replied back to Greg, pointing to the 
"otrfileconverter" project (which seems to *only* outputs to 
Gibberbot format), I call that a *problem*, not a *solution*.  It's 
a big problem that each and every IM client will eventually all 
need to invent their own conversion utility, and then try to keep 
up to date with how to convert between all the different IM client 
storage methods.  As the number of IM clients supporting OTR 
increases, there will be an ever-expanding need for more conversion 
tools, and for more IM clients to be supported within each 
conversion tool.

Cypherpunks, pretty please nip this in the bud, and please fix this 
problem upstream.  You guys *are* the upstream.

Even a one-page document/web-page would probably be enough.  How's 
this for a start?

Unix: ~/.config/otr
Windows: %APPDATA%\OTR
OS/X: ~/.config/otr


Much appreciated!