Hi, I'm currently trying to implement RPC level 2 (for the OCaml RPC implementation - see https://github.com/mirage/capnp-rpc#encryption-and-authentication for the current status).
I have some questions... https://capnproto.org/cxxrpc.html says: Current Status: As of version 0.4, Cap’n Proto’s C++ RPC implementation is > a Level 1 implementation. Persistent capabilities, three-way introductions, > and distributed equality are not yet implemented. > But I imagine this is out of date. The RPC spec says: How exactly a SturdyRef is restored to a live object is specified along > with the SturdyRef definition (i.e. not by rpc.capnp). > and However, in practice, the ability to restore SturdyRefs is itself a > capability that may require going through an authentication process to > obtain. Thus, it makes more sense to define a "restorer service" as a full > Cap'n Proto interface. If this restorer interface is offered as the vat's > bootstrap interface, then this is equivalent to the old arrangement. I imagine this must be some network-realm-wide restorer API, because if every SturdyRef has its own restorer API then an RPC implementation won't know how to authenticate to it when the user does something like: liveRef := sturdyRef.getRcvr() Is this restorer API specified somewhere? The Python docs mention an *ez_restore* method and say "Refer to the Cap’n Proto docs if you don’t know what this means", but it's not clear to me what I should be looking at. For now, my SturdyRefs can only refer to bootstrap services. Also, I couldn't find much about authentication. https://capnproto.org/rpc.html#encryption says: At this time, Cap’n Proto does not specify an encryption scheme, but as it > is a simple byte stream protocol, it can easily be layered on top of > SSL/TLS or other such protocols. > For now, I have used TLS with self-signed non-expiring certificates (just as a container for the public key) and a validator that checks a hash of the server key fingerprint. My SturdyRefs convert to URIs that currently look like this: capnp://sha-256:[email protected]:7000 (based on the format at http://iiw.idcommons.net/HTTPSY_%E2%80%93_Leave_the_Certificate_Authority_Behind ) However, https://capnproto.org/roadmap.html says: Cap’n Proto RPC should support an encrypted transport which uses > capability-based authorization (not PKI), can accomplish zero-round-trip > three-party introductions (via a pre-shared key from the introducer) and > based on modern crypto. TLS is not designed for this, but we don’t want to > invent new crypto; we intend to build on libsodium and the Noise Protocol > Framework as much as possible. > For interoperability, I allowed "insecure@" to disable encryption. e.g. to connect my OCaml client to the C++ calculator service I can use: capnp://[email protected]:7000 I treat an empty host:port section as requesting a Unix-domain socket, e.g. capnp://insecure@/tmp/calc It's a bit of a hack, but I'm not sure what would be better. Things I'd like to know: - Do any other implementations support authentication or encryption? - Has anyone else defined a URI format I can use for sturdy refs? - Where in the URI should I put the service ID for the restorer server? - Is there a spec defining what a StudyRef and restorer service should look like for the default public Internet? If not, is there anything obvious I should change in my current implementation to match what this will look like? Thanks, -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
