* Is there any reason for not using the standard file format for public
and private rsa and dsa keys? (i.e. those that you'd get with ssh-keygen)
What we need is a way to 1) store key information along and 2) store
some other data per key, such as protocol name and accountname.
Ideally the format should be easily read/written (that's why I've
thought of XML).
I think the standard pub/priv key format just stores the keys
sequentially in a plaintext file, so it cannot satisfy requirement 2.
If I am wrong (i.e. it can store additional data per key), we can use
* I don't quite understand why we need to map protocol names to keys in
the keyfile, or even in the library itself. If I understand correctly,
OTR is supposed to be a protocol agnostic mechanism so adding protocol
names in the key files seems kind of redundant.
The general idea of Authenticated Key Exchange (AKE) in OTR is that
Alice and Bob do an unauthenticated Diffie-Hellman (D-H) key exchange
to set up an encrypted channel, and then do mutual authentication
inside that channel. To perform mutual authentication, Bob and Alice
must have long-term public keys. (this does not answer your question,
but I mention it for completeness)
So, when a remote user sends us a query message (which we receive
through a specific account/protocol), at some point we must
authenticate our self by signing some data.
To answer your question why we need to map protocol names to keys, we
need additional information per key (account and protocol) because
there is not a "super" key for all our accounts, each account should
have it's own public key, so account/protocol is used much like an
identifier for each key (we can thing of it like a 2-field primary
As far as why store it in a key file and not anywhere else or why
should the library implement that feature, I guess because we don't
want to force any application using OTR to implement it's own key
management mechanism. This is not a requirement though, if we want SIP
Communicator (or any other IM) to handle key information, we can
As for storing XML. Currently we do this with the ConfigurationService.
One way to solve the whole thing would thus be to make the OTR bundle
(and not the lib) pick a location for storing all keys, and map the
various keys to specific accounts by storing the bindings in the
ConfigurationService. It could then pass the key locations to the OTR
lib so that it would do its magic.
Does this make sense?
This idea could not have been any better, it makes perfect sense.. (if
I had written this from the beginning I wouldn't have written all of
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com