#social 2017-09-28
2017-09-28 UTC
# 
cwebber ajordan: yeah those were more innocent times ;P
# saranix There hasn't actually been a real, productive CG meeting in like 2 months...
# cwebber maybe biweekly isn't helping
# cwebber it's easier to forget about and when we do have topics and people get excited it seems to have been happening on the off-weeks
# cwebber though we had one a month ago
# cwebber so it's not two months
# cwebber just a month
# cwebber aaronpk: WDYT?
# cwebber other input welcome too, not just aaronpk
# saranix I didn't consider the 8-30 meeting to be very productive ;-)
rowan joined the channel
# 
ajordan !tell tantek ugh, IWC NYC looks so fun! probably too late to get train tickets, etc., however I *did* announce it to the folks in the programming institute I was in over my gap year (Recurse Center, https://www.recurse.com/) so hopefully you get some alumni and in-batch folks who show up!
xmpp-social, cdchapman, olistik, tantek, rowan and dlehn joined the channel
# dlehn cwebber, Gargron: hi, I noticed "RsaSignature2017" code here: https://github.com/tootsuite/mastodon/pull/4687/files#diff-3ba87cae7c6204004f3b61736192369d
# dlehn it's not doing what is in the spec here: https://w3c-dvcg.github.io/lds-rsa2017/
# dlehn I think that spec needs a bit of clarification, which I noticed as I was adding support to jsonld-signatures lib. idea is to use JWS signature format. in particular, using the compact representation with detached content. so you get
{b64header}..{b64sig}. omit the payload since in this case you can recreate it from the document and other signature options# dlehn looks like that mastodon code is doing something more like LinkedData2016 format (which may not really be specified anywhere?)
rowan, cdchapman and tantek joined the channel
# cwebber dlehn: the LDS spec doesn't do a good job of separating out the suite algorithms logically
# dlongley true story, it should also say, instead of "For example, RsaSignature2017" => "The types to use are defined in each signature suite specification that extends this specification."
# dlongley or something to that affect
# dlongley it should be clear that Linked Data Signatures 1.0 is layered
# dlongley and you need to implement another signature spec on top of it
# dlongley not just put any "type" you want into the type field as some readers may (did) read
# cwebber but I think the issue here is maybe that Mastodon is currently using a mix of things? I'm in a meeting and don't have time to review :)
# cwebber dlehn: could you file a bug on mastodon?
rowan joined the channel
# Gargron wow well
# Gargron this code is out in the wild
# Gargron i followed the examples from the spec
# dlongley Gargron: so are there signatures that are being created?
# dlongley is it too late to fix?
# dlongley the only difference, i think, is that your implementation is signing the payload ...
# dlongley and it should have been signing: <jws-header>.<payload> instead
# dlongley so it's compatible with JWS
# dlongley one option is to look at timestamps when doing verification and if a signature was generated before the fix don't include the JWS header when checking
# dlehn and the output has to be the jws detached payload format
# dlongley so we don't have to change the RsaSignature2017 spec or anything else ... it would just be a tiny bit of backwards compat code.
# dlongley dlehn: can we easily look at the output and determine if it's in that format or not?
# dlongley because Gargron's code could just do that
# dlehn i suppose? check for the '..' in the middle or something?
cdchapman, rowan and rowan_ joined the channel