[OTR-dev] RFC standardisation

[Ximin Luo]

On 12/07/13 20:06, Paul Wouters wrote:
> 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 "failed", just "not succeeded yet" - there is plenty of time. :) Or did you
have a better candidate in mind? What's that draft you're mentioning?

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

The issues you mention here, I don't think of as flaws at all. The whole point
is that, in the WoT, trust is sourced from, and rooted at, *yourself*, when you
sign other people's keys personally. OTOH, hierarchical PKIs source their trust
from some unrelated root CA that happens to be default-trusted by your software
(but then how can you be sure you got your software correctly?).

So, I see the latter as sacrificing a bit of security for convenience - but
ultimately I would much rather trust myself than some arbitrary root CA.

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

Cool, keep us updated!

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20130713/64cbbaab/attachment.pgp>