Re: [openpgp] AS2+OpenPGP protocol extension review request

[Ben McGinnes <[e-mail]>]

On Tue, Feb 12, 2019 at 11:52:05AM +0000, Stephen Farrell wrote:
> 
> Hiya,
> 
> I just had a quick peek (will try read more later) but wondered
> why PGP is a better primitive here than MLS? [1] (Or one of the
> IM security schemes that motivated MLS, if dealing with a work-
> in-progress like MLS is problematic.)

I was about to say MLS is *way* overkill, but then realised you were
referring to the more recent MLS[1] and not this MLS.[2]

Anyway, there were several reasons; including, but not limited to,
these:

 1. Responding to frequent requests of users of Mastodon and Pleroma
    servers who have been requesting specific software solutions of those
    platform (most commonly citing Mailvelope or Keybase).
    
    I wanted to get the thing out of the realm of vendor or language
    lock-in.
    
 2. ActivityStreams 2.0, in spite of the name, does not actually use
    live streamed data in the same way as various IM protocols do, it
    really is a transport protocol only.
    
 3. OpenPGP provides an existing and proven means of meeting all the
    cryptographic shortfalls of ActivityStreams and the fediverse.
    
 4. I've deliberately designed this extension in a way which would
    enable an alternative cryptosystem to be designed for it or adapted
    to it in the future.  So no protocol lock-in either.
    
 5. None of the IM cryptosystems I thought of would meet all the needs
    of various people whose requests I read and most of them are solely
    dependent on either SSL or libsodium to the exclusion of all else.
    The former tends towards mis-implementation and various exploits, the
    latter tends towards trying to make the one thing it does do fit
    everything.
    
    It could be argued that that latter criticism is also true of
    OpenPGP, but on the other hand OpenPGP and, particularly GnuPG,
    can do an awful lot more too.
    
 6. I've spent far more time delving into GnuPG's innards than most of
    the other systems, so there was a little bias there.  Still, that's
    another reason for defining the spec in such a way that an
    alternative cryptographic protocol could be used instead.
 

Regards,
Ben

1: https://tools.ietf.org/wg/mls/
2: https://en.wikipedia.org/wiki/Multilevel_security