[OTR-dev] RFC standardisation

[Paul Wouters]

On Fri, 12 Jul 2013, Ximin Luo wrote:

> My original intention in asking about an RFC for OTR is because I wanted to
> have some reference material for my intention to push forward the encoding of
> OTR keys as sub-keys in a PGP key, similar to what monkeysphere does for SSH keys.

The public key format I ended up using is the same as in the OTR spec,
except I added three fields:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+-------------------------------+---------------+
      !    protocol   !            Key Type           !  Hash Type    |
      +---------------+-------------------------------+---------------+
      !                                                               !
      ~                      Fingerprint data                         ~
      !                                                               !
      +---------------------------------------------------------------+

Protocol is the OTR protocol version (eg "3"). Key Type is the key type
used in the OTR spec as well (currently only 0x0000 for DSA is defined.
While the OTR spec only allowed for SHA-1, I used a hash type value so
we can migrate to other hashes (eg when FIPS bans use of SHA1 within the
next few years).

The fingerprint data calculation for DSA keys is also taken from the OTR spec.

> I am very interested in trying to promote a decentralised PKI and I think PGP
> is the best existing candidate for that.

If PGP is your "best candidate", then I'd argue decentralised PKI has
horribly failed. Which is why I'm also writing an OPENPGPKEY draft :)

> Not that I am opposed to dane-otr (and its counterpart for SSH keys, RFC 4255;
> thanks for the info) - it's likely to be more immediately usable on a global
> scale than any decentralised PKI that crops up in the near future, but I think
> in the long term a hierarchical PKI (especially one tied to DNS which somewhat
> monopolises who can actually run a CA) is harmful.

I am thinking of two things regarding PGP. The location of a public key
is non-standard, and there is currently no easy method for a MUA or MTA
to pick "encrypt to this key instead of sending plaintext" because
anyone can upload a key with someone elses email address. Using a PGP
public key in DNS, signed with DNSSEC, solves these two issues.

It does not replace the "web of trust". But it does provide "better then
nothing" encrypted email.

I'll upload my two drafts to github over the weekend,

Paul