[Someone please supply a link/text describing the exact form of this conundrum, which I will happily replace this text with.]
[See also Conundrum: Testing for EQ]
This discussion is one we need to have early in the project, so I’ll kick things off.
- E has both sturdy and live refs.
- Waterken had YURLs, which were essentially sturdy refs.
- Client Utility had only live refs with a separate step to set up the channel.
- Macaroons and our Zebra Copy work are based on certificates, which were neither (both?).
What other systems should we look at?
There are pluses and minuses to each.
- The existence of sturdy refs makes distributed garbage collection hard. Waterken explicitly ignored this problem, observing that persistent storage is cheap and getting cheaper. Is that a philosophy we want to adopt.
- Live refs don’t give any authority to a passive attacker who is limited to reading what is sent on a communications channel. Is that property important enough to balance the need for some other mechanism to set up a secure channel?
- Certificate-based schemes require a lot more crypto than do sturdy and live refs, which can rely on TLS. The do allow for off-line delegation. Is that feature worth the added complexity and computation?
What else do we need to consider?
Our choice may depend on what use cases we consider to be important. We chose SAML certificates for Zebra Copy because our enterprise use cases did not require extremely low latency and because we could rely on corporate IT people to handle the complexity. We chose live refs for CU to reduce computational complexity and because of the way it fit the rest of the design. I believe Tyler chose YURLs because of the fit to the web.
What use cases are most important for Spritely?
1 Like
As the author of some old attempts at ActiveCapCerts I can probably illuminate the certificate route a bit.
One thing is that certificates actually do not require more crypto than TransportLayerSecurity does. Just diffrent libraries such as OpenPGP or other such libraries that makes signing and verifying signatures straight forward.
What an cert supporting vat need to do when handling a cert is to:
- verify that the cert is signed by the cert issuers given public key. (Edit: Given in the cert)
- interpret the payload to do the attenuated delegation.
The 1st one is a solved problem but the 2nd one was much harder to solve.
So, I took a leaf from Nikta’s paper (alternative) and instanciate an code evaluator with safe environ that has been augmented slightly.
The augmentation is to provide an issuer spefic facet to the handoff table mechanism used by CapTP and use the issuer public key as the vatid as if the issuer was an remote vat on the other end of an CapTP connection.
Another augmentation is two boolean functions that compares current time is less than or greater than, respectively, given timestamp for exipry and maturity control.
This solution has the same issues as any that uses safe evaluators in regards to denial of service and resource consumption attacks.
3 Likes
The OAuth 1 folks believed this argument would lead to secure deployments. It didn’t. No matter how many tutorials, no matter how many quality libraries, developers got it wrong. An important design principle of OAuth 2 was that TLS was the only crypto developers needed. We should to consider that lesson before adopting certificates as capabilities.
1 Like
(I think you mean signed by the private key.)
A certificate is issued to a public key and signed by a private key known to the creator of the certificate. How are we to know if that private key is the issuer’s given key? The answer is we often can’t without something like a certificate authority.
The problem arises when we cross jurisdictions, such as company boundaries. Alice delegates to Bob who delegates to Carol. Alice may never have heard of Carol. In fact, she can’t know if Carol is Bob’s sock puppet. Similarly, Carol may never have heard of Alice and may have no way to verify Alice’s public key.
I think it’s better to use one-off key pairs. A key pair can be generated when an object is created. The initial certificate is issued to that public key, and a delegation or use of the capability is signed with the private key. When Bob wants a delegation from Alice, he creates a key pair and sends the public key to Alice. Alice issues the new certificate to that public key and remembers that she delegated to Bob. Bob does the same when he delegates to Carol. If Carol misuses the capability, Alice will come after Bob. It’s Bob’s responsibility to go after Carol.
Yes, sorry, signed by the private key.
Never said that an active-capcert issuer was a person.
And the issuer of an active-capert is only identified by its public key or cryptographic hash there of. Just like the vatid of an E vat.
Active-capcerts as described above really only needs two methods from a cryptography standpoint: sign and verify.
Great post, @alanhkarp! You really summarized things well.
We definitely want cooperative GC. Virtual worlds are yet again another useful way to think of it: without GC your server is going to get filled up with the corpses of bat enemies that players have defeated and no longer care about.
Sturdyrefs definitely make the problem difficult. One “simple, common solution” is to have a refresh method on most sturdyrefs that express that “I’m still interested in this!” (The alternative is a refresh pattern where you get a different capability, but in my experience that’s less desirable unless you really need it… it’s hard to update all old references.)
You
but you did refer to
which implies that the key was provided by some sort of authority. You now say
The word “its” implies that the issuer has a specific key.
My point is that the issuer should create a key pair for each use, avoiding all the problems of trying to decide who the issuer is by association with some specific key.
1 Like
The OAuth 1 experience was that developers couldn’t be relied on to get those steps right even with the availability of high quality libraries. One instance from my personal experience was someone getting confused about when to use a public key vs. the corresponding private key.
To be clear, I’m not saying we cannot use cap certs for this reason. Just that we need to be aware of the pitfalls. As the saying goes, “A fool learns from his own mistakes; a wise man, from the mistakes of others.”
Can this refresh mechanism be associated with an expiration time? That’s something common in certificates, but I haven’t heard of the idea being associated with E-type sturdy refs.
I have edited my post to try to stem the lingustic confusion a bit.
Thanks. That helps a lot.
Yebb, this is why I have formulated, only in my Icelandic notes, something I call PostalRefs that are kind of Far refs.
One uses a constructor which is given a ActiveCapCert and gets back a PostalRef and a PostMeister. The PostalRef can be eventually sent to and the resulting promises are also PostalRefs. (Basic promise pipelining contagion afaiui)
When these PostalRefs have accumulated enough eventual sends, deemed by the programmer using them, PostMeister can be asked for the parcels generated. Those parcels are ActiveCapCerts that carry those eventual sends.
I have yet to figure out how to await on these PostalRefs though.
The gist of the idea is that client programmers do not need to, usually, think about public or private keys.
1 Like
SturdyRefs in CapTP of E and their cap uris equivs have optional expiry date. Using some sort of refresh on sturdyrefs at a time x interval away from the expiry is an idea worth investigating.
Expiration times are fine, but things get complicated when the sturdy refs are shared. Either you remember everyone you shared it with, or you let their request fail and share the new one. Neither is ideal.
I think you misunderstood me.
Let me clarify with an example.
Lets say we have a SturdyRef A_t1 to AliceObj. That SturdyRef has expiry 30 days from now, so eleventh of November this year.
Lets say there is a convention to start trying to renew such SturdyRefs one week before its expiry.
Bob, Carol, and Dave all had gotten hold of a datacopy of SturdyRef A_t1.
All three notice that there is about a week to its expiry and start contacting Alice vat about getting a renewed or new SturdyRef to AliceObj with either unlimited expiry or expiry quite further into the future. Some of them might succeed in time. Let the new SturdyRef be called A_t2.
Quite some time later, Elaine comes across a three year old copy of SturdyRef A_t1 and knows just from the expiry it is pointless to try to get a liveref from it.
(btw have been in Elaines shoes with a quite an old phone number that became invalid after a phone number flagday in the UK)
The question comes down to who can get a new version of the sturdy ref. Is it only the person who was given the original? Is it anyone who currently holds it? Each has problems.
In the former case, each delegatee must get a new one from their delegator. In the latter case, you might be violating the delegator’s policy that would not give a new copy after expiration. These problems are not intractable, but they need to be considered.
1 Like
Hmm… having an ref to a renewer or some such in the sturdy ref?
Enabling such policy decisions as you stated/asked is worth considering.
OAuth has the concept of a refresh token, a "renewer’ in your terminology. It’s a separate token, so the delegator can choose to give the refresh token when giving the short-lived bearer token. There’s no reason something similar can’t be done with sturdy refs.
1 Like