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.
Description: PGP signature
_______________________________________________ openpgp mailing list openpgp@xxxxxxxx https://www.ietf.org/mailman/listinfo/openpgp