[sip-comm-dev] GSoC OTR Question - Reading/Writing XML


#1

Hello all,

As any OTR implementation (libotr for example, the C++
implementation), our own java OTR implementation has to store private
keys and public key fingerprints on disk as they are required for
authentication. I have attached a file produced by libotr.

I was thinking to store this information in XML format like this (the
format is not final, just a though):
<privkeys>
    <privkey account="someaccountname" protocol="MSN|Jabber|..."
type="DSA" key="99sd9933........">
</privkeys>

My question is, is there a simple hassle free way to read/write XML?

Default_otr.private_key (435 Bytes)


#2

Hey George,

Apologies for the delay. Here are my thoughts on the subject:

* 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)

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

* Mapping keys to accounts makes more sense although if it was up to me
I'd prefer using the same key regardless of the account. Anyways, I do
realize the privacy concerns here. However, once again, should it really
be up to the OTR library to take care of this? I'd expect the lib to
simply generate, store, and retrieve keys from locations specified by
the application.

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?

Cheers
Emil

Geekius Caesar wrote:

···

Hello all,

As any OTR implementation (libotr for example, the C++
implementation), our own java OTR implementation has to store private
keys and public key fingerprints on disk as they are required for
authentication. I have attached a file produced by libotr.

I was thinking to store this information in XML format like this (the
format is not final, just a though):
<privkeys>
    <privkey account="someaccountname" protocol="MSN|Jabber|..."
type="DSA" key="99sd9933........">
</privkeys>

My question is, is there a simple hassle free way to read/write XML?

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello Emil,

* 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
that instead.

* 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
key).

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
implement that.

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
the above..)

Best,
George.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Correction: s/I had written this from the beginning/I had read this
from the beggining

···

On Tue, Jun 16, 2009 at 10:58 PM, Geekius Caesar<geekius.caesar@gmail.com> wrote:

Hello Emil,

* 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
that instead.

* 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
key).

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
implement that.

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
the above..)

Best,
George.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net