Hi all,
I just finished typing up an architecture draft for Interpeer. It's at https://specs.interpeer.io/draft-jfinkhaeuser-interpeer/
The last months have been rather frantic in that I wanted to bring so many development and documentation activities to a close. In the meantime, some thoughts kept nagging at me about the work that needs to come still.
Then I went to Prague to attend IETF118. And while I realized that a lot of what is going on there is not really of much benefit to Interpeer and vice versa, I did have just the right amount of very enlightening conversations to kick my old noggin into high gear. Finally everything clicked. The architecture documented I had promised to write to a number of people suddenly *needed* to be written, and here we are.
I feel it's rough; it needs inputs and questions, probably misses a few bits, and could almost certainly benefit from an editor. But it is a lot better than me trying to find new ways of explaining the same thing over and over in person.
Jens
Interpeer gUG (haftungsbeschraenkt), Greifenberg
Registered: Amtsgericht Augsburg, HRB 37686
Geschaeftsfuehrer: Jens Finkhaeuser
https://interpeer.io/
----
From: jens(a)interpeer.io
To: interpeer(a)lists.interpeer.io
Nov 30, 2023, 2:29:19 PM
Hi all,
in the last days, CAProck has gotten some attention and feedback, from people I happen to know are subscribed to this list. So rather than having multiple conversations in parallel, I'd like to summarize here for everyone what is being discussed, and then we can take things from here. (Note, of course, that it's still fine to reach out to me individually.)
Post-quantum security
There is some valid concern that PQ secure signatures will produce signatures larger than fit into the 64 Bytes that are currently allotted in the specific CAProck scheme, and perhaps even larger than will fit into the ~1200 Byte MTU we're assuming for our 0-RTT authorization. This is somewhat deliberately not addressed at this point, largely because as a practitioner I'm waiting for e.g. NIST recommendations on such signature schemes. But it's clear that this will need addressing.IETF Hackathon
Yes, absolutely, if I can manage to attend an appropriate IETF conference, I would love to put this project on the hackathon list. Mostly, I have budget constraints that mean I'm more likely to attend EU conferences, but your employer *hint hint* may be open to make a donation.More complex assertations than authorization tuples
MACAROONs or Soutei (not yet added to the draft) replace the authorization tuples with more complex scripts that a recipient can execute to verify whether the requester for a resource matches some attributes (or the object, for that matter) rather than identifying them directly. The result can be considered something of an ephemeral identity. Because a request will specify an action (implicitly or explicitly), and both subject and object can be ephemerally identified in this way, the notion that a request resolves to the boolean presence or absence of an authorization tuple still holds.
But the draft is not very clear on this distinction, and in its current form requires that this resolution happens (by whichever means) on the side of the resource owner/issuer/grantor. It would likely be beneficial to open this up a little, and explain that the tuple can be replaced by other assertations without impacting the scheme overall *as long as* the assertation does not introduce some third party resource that can become an SPoF again.
Let me know if you'd like to contribute appropriate section(s) to the draft(s); a simple PR on https://codeberg.org/interpeer/specs is a great starting point. And you may/should absolutely add yourself as co-authors if you make such contributions!
Jens
Interpeer gUG (haftungsbeschraenkt), Greifenberg
Registered: Amtsgericht Augsburg, HRB 37686
Geschaeftsfuehrer: Jens Finkhaeuser
https://interpeer.io/
----
From: jens(a)interpeer.io
To: interpeer(a)lists.interpeer.io
Nov 5, 2023, 11:44:37 AM
