On Wednesday, August 23, 2017 at 3:48:45 PM UTC+1, Thomas Leonard wrote: > > 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. >
It seems that this uses the "deprecatedObjectId". The spec says it's deprecated because: 1. "in practice, the ability to restore SturdyRefs is itself a capability that may require going through an authentication process to obtain." 2. "the earliest version of the EZ RPC interfaces set a precedent of exporting multiple main interfaces by allowing them to be exported under string names" 3. "Often, "main" or "well-known" capabilities exported by a vat are in fact not public: they are intended to be accessed only by clients who are capable of forming a connection to the vat." and "the supervisor has to be careful not to honor an external request addressing the application's default capability". However: 1. If a sturdy ref is a capability reference then holding it should be sufficient to use it, without needing additional capabilities. It's not clear why the spec thinks this isn't enough. 2. It's not clear why one implementation using string names means the protocol needs to change. 3. This seems like a sandstorm-specific problem, and could be fixed in one place (the supervisor). As a safer alternative, sandstorm apps could instead use a pre-exported "export 0" for their admin API. The protocol should already prevent external clients from getting access to unrelated exports. Given the lack of an alternative, I've implemented this "deprecated" scheme in the OCaml version now. It seems to work fine, and works with the other implementations. > 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? > I'm now storing the service ID, base64-encoded, as the final path component in the URI. > - 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? > I also have some additional questions now: - The schema language doesn't define a SturdyRef type. Since it seems that interfaces shouldn't contain network-specific types, this means that SturdyRefs currently have to be defined as AnyPointer. It would be useful if the spec could pre-define this abstract (and generic) type. Then schema compilers could output type-safe code for building and reading them. - It seems that sturdy refs are intended to be stored as plain data. However, this is usually readable by the application code. Perhaps they should instead go in the CapDescriptor table? The spec says: "we specify several "parameter" types. Each type is defined here as an alias for `AnyPointer`, but a specific network will want to define a specific set of types to use. All vats in a vat network must agree on these parameters in order to be able to communicate. Inter-network communication can be accomplished through "gateways" that perform translation between the primitives used on each network; these gateways may need to be deeply stateful, depending on the translations they perform." Does "deeply stateful" mean that gateways need to understand the schema to know which fields are sturdy refs? -- 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.
