describe furlification
[Imported from Trac: page AccountingDesign, version 8]
parent
ddbc56b1b3
commit
b260694faf
|
@ -211,3 +211,58 @@ storage has been delegated.
|
|||
* `base32(pubkey): PETNAME\n`
|
||||
* if multiple pubkeys map to the same pet name, their usage will be added
|
||||
together at display time.
|
||||
|
||||
## Furlification
|
||||
|
||||
An authorized client will have a private key and a certificate chain that
|
||||
authorizes that privkey to perform some operation. Since we use Foolscap to
|
||||
perform storage operations, we need a way to get from the cert-chain/pubkey
|
||||
world to the live-`RemoteReference` world. (an alternative would be to
|
||||
sign each storage operation, encrypting the result to some public key for
|
||||
confidentiality, but we would prefer an approach that does not require quite
|
||||
so many expensive public-key operations on the server). This process is
|
||||
called "furlification", since it serves to convert the certchain+privkey into
|
||||
a FURL that references an object which has the delegated authority.
|
||||
|
||||
The process starts by creating an encoded message that looks very much like
|
||||
the certificate described above. This message can contain any of the
|
||||
limitations or attenuations that the cert-chain message holds. But instead of
|
||||
a field named `delegate-pubkey`, it will have one named
|
||||
`beneficiary-FURL`. This message is signed by the private key that sits
|
||||
at the end of the certificate chain. Then the cert-chain, the message, the
|
||||
signature, a nonce, and one other argument named "precache-ignored" are all
|
||||
sent to the storage server's "login" facet. The return value from this
|
||||
message is ignored.
|
||||
|
||||
After checking the signatures, the login facet is then required to create a
|
||||
new `foolscap.Referenceable` object with the given authority (called the
|
||||
"operational object", or "Personal Storage Server Facet"), and to send
|
||||
(nonce, object-FURL, object) to the client-side object designated by the
|
||||
beneficiary-FURL. Any successful return value from this message is ignored
|
||||
(although it may raise `AuthorityExpiredError`, see below).
|
||||
|
||||
The beneficiary-FURL is used for the return path (instead of the return value
|
||||
from the login message) because the server that receives the signed message
|
||||
could easily forward it on to server2 in an attempt to steal the
|
||||
corresponding server2 authority. Since server2 will only send the operational
|
||||
object to the beneficiary, server1 cannot benefit from this sort of
|
||||
violation. However, to avoid a Foolscap round-trip, the beneficiary object is
|
||||
sent as the "precache-ignored" argument: this allows Foolscap to pre-cache
|
||||
the beneficiary without harming any of the security properties.
|
||||
|
||||
The object-FURL is expected to be persistent: clients should be able to cache
|
||||
them for later use (to reduce the number of pubkey operations that servers
|
||||
are required to perform). The object itself is sent in the beneficiary
|
||||
message mainly to pre-fill the Foolscap table; the client is allowed to
|
||||
either use the object directly or to getReference the object-FURL.
|
||||
|
||||
Servers are expected to create a FURL that contains a MAC'ed description of
|
||||
the object's limitations (and use Foolscap's Tub.registerNameLookupHandler),
|
||||
rather than maintain a big table from random swissnum to object description.
|
||||
Servers can include expiration times in these swissnums. If the client
|
||||
experiences `AuthorityExpiredError` when using their object reference (or
|
||||
when using getReference on the object-FURL), they must attempt the login
|
||||
process again with a new signed request message. If they experience
|
||||
`AuthorityExpiredError` during the login process, then part of their
|
||||
certificate chain may have expired.
|
||||
|
||||
|
|
Loading…
Reference in a new issue