Hi all,
For those of you either not subscribed to gnupg-devel or who
may not have paid as much attention to it over the new year period;
I've been working on a little thing which is ready for some form of
peer review.
Essentially it's a design for extending the W3C's ActivityStream
version 2.0 (AS2) and ActivityPub (AP) protocols for federated social
networks (e.g. Mastodon and Pleroma) with OpenPGP in order to provide
a host of features not inherently built into AS2 and AP.
The AS2 and AP designers considered it, but realised that they didn't
have enough cryptographic knowledge to design it in a way that
wouldn't shoot someone in the foot; and so they did the responsible
thing in not making assumptions. Instead leaving things open for that
void to be filled later.
I found their work early last year and, upon reading the specs,
realised that I was looking at a transport protocol. Not only that,
but all the most essential cryptographic functions which needed
filling were already thoroughly addressed by another existing
protocol: OpenPGP.
My post on this thing to the gnupg-devel mailing list is here:
https://lists.gnupg.org/pipermail/gnupg-devel/2019-January/034167.html
The W3C AS2 and AP specifications are here:
https://www.w3.org/TR/activitystreams-core/
https://www.w3.org/TR/activitypub/
My extension proposal is the second draft and the first draft that has
been posted publicly (the actual first draft was sent to the W3C AS2
designers, a couple of GnuPG developers and a handful of others). My
design document is available here:
https://files.de.adversary.org/crypto/ac/index.html
The supplemental files (including public and private keys used in the
examples) are here:
https://files.de.adversary.org/crypto/ac/supplemental.zip
Note: files.de.adversary.org is an AWS S3 bucket, so it will trigger
an SSL cert error. Ignore it or drop back to HTTP at your own
preference.
Anyway, there are a number of people on this list in particular who I
think could make sure that I haven't catastrophically cocked the whole
thing up. I don't think I have, but that's precisely when you should
double-check to be sure.
So if as many of you as can spare the time could please weigh in and
try to pick it apart; that'd be greatly appreciated. It'll help make
it stronger. Those of you who've already been down the protocol
design path are amongst those I'm particularly keen on checking this
thing.
I do realise there are still matters to discuss and finalise with
regards to transmission of keys; currently there are multiple options
included and I expect some discussion around that. There's also two
versions of the Encrypted Note and I'm inclined to favour the second,
slightly more complex version for a number of reasons; including
working with other functions (like nesting a Signed Note inside it in
a similar manner to signed & encrypted PGP/MIME emails).
Regards,
Ben
P.S. I'm cross-posting this to the IETF OpenPGP WG mailing list on
the off chance that there might be subscribers to that who are
not also subscribed here or to gnupg-devel. That may not be
very likely, but it is possible and so a copy there doesn't
hurt. Apologies to those who will see it twice as result,
though. Especially since you're the ones I'm most keen to want
reviewing this work.
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp