Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security)

[Daniel Carosone]

On Mon, Oct 20, 2008 at 02:30:27PM +0200, Markus Wanner wrote:
> Looks like we are just approaching the problem from different angles.
> I've been analyzing what's required to convert to atomic certs (or
> super-certs or whatever you'd like to call it). I'm thinking that we
> need to clean up our current certs to be able to convert them.

Ah, okay.  I agree, but I'm not sure about the need for strict date
ordering as part of that cleanup. 

> > sync these revisions in a limited context (such as between my own
> > machines just for backup purposes).[*]  Secondly, the decision for
> > when I'm ready to publicise that work is rarely date-based.
> 
> I fully agree here. I'm in the need for such a feature often enough as
> well. But it looks like it depends on atomic certs *and* policy
> branches, so we are not likely to get that feature in the near future,

Not really - in fact it can be done today using just private beanch
names, although it's not as convenient.

As for the candidate use cases I suggested..

> > validity time comes around, the build slaves suddenly see all the
> > summary certs for the day, and build the latest (by ancestry) rev with
> > a valid cert.
> 
> Hm.. do we really want to dig into scheduling of build bots? I don't
> quite think that fits the scope of monotone. Certainly not yet.

Not explicitly, and of course you could always use a custom cert that
contained a 'build schedule instruction' with a date as part of its
own syntax.

> > Oh, as a somewhat dumb use for a "valid-until" field: a suspend cert
> > for a head I want to come back to -- but not until next month. 
> 
> You can 'un-suspend' the branch at any time by simply committing a new
> revision. So I don't think this us an utterly needed feature.

No, but it's a way (not necessarily the best way) of reminding myself
to do this.

> > Or another: a tag cert that names the current base for patch
> > submissions for the next quarterly integration branch.  Next quarter,
> > the tag expires and a new one is made.
> 
> Hm.. that might count. Although, doesn't policy branches provide a more
> flexible mechanism to do these things? (I.e. general purpose cert
> revocation, instead of only time based).

In at least one view of branch policies, all naming (including
revision naming aka tags) becomes a policy file statement, so they
wouldn't even be certs as now.

Cert revocation or superceding of one cert with another (cert DAG) is
a mostly-separate issue, more closely aligned with a new cert format
than with policy.

> > Or another: maybe I'm doing a ZipperMerge, with an explicitly-named
> > intermediate zipper branch in the middle; perhaps I expect to take a
> > [..]
> > until then - if expired certs aren't sent via netsync, they no longer
> > need to be passed around the rest of the world. 
> 
> Again, sorry, but I don't think saving a few kbytes for these certs is
> worth the effort (and confusion) introduced by certs expiring by date.

Agreed, and I could also just use a private branch name that doesn't
fit my sync pattern.

So, I wasn't expecting any of these examples to be conclusively
convincing, and it seems they weren't.  Are there any others?

To be honest, the best example for a date-based 'valid-after' trigger
also requires revision encryption, and even then is not a perfect
match to the requirement.  When coordinating security fixes, there is
often a need to collaborate on developing and testig the fix, and yet
still keep the details of the change secret until a known embargo
date.  Once that embargo is lifted, you suddenly want very wide
distribution and availability of the same fix, including its tested
and certified merge into one or more release branches.  The same kind
of requirement can be found for new product launches and other
press-release type material, where you want many views of the same
information to be updated at the same moment.  The trouble here,
still, is that these embargo dates often shift around, so can't 
really be fixed in certs that would automatically allow publication
based on a previous idea of a publication date.

Regardless of whether there are clear good uses for future-dated
certs, or future-dated / out-of-order date certs on revisions, I'm
still not convinced that they should be treated as some kind of error
(beyond at most diagnostic-like messages and db check).

> > [*] I have in mind a different mechanism for this, based on a concept
> > of key-based netsync communities (to mostly replace the current
> > netsync permission hooks), which I've never taken the time to
> > write down - in part because I haven't really thought about how it
> > intersects with branch policy, and in part because I'd really like to
> > think of a nice way to make it work for revision encryption too..
> 
> Sounds very much like something that could work together with policy
> branches, no?

Yes, but the idea pre-dates policy branches and hasn't really caught
up, for lack of attention since.  I imagine users and servers would
join netsync communities along with other delegated trust settings
taken from the policy they subscibe to, certainly.

The very basic idea is that each party to a netsync has an identity,
based on their keys.  This identity authenticates each party as a
member of one or more netsync communities (groups), and branches
are also associated with these communities. The netsync only sends
branches associated with the communities the sender knows the receiver
as belonging to (ignoring some other subtleties like exclude patterns
for now). 

At its simplest implementation, it's just a level of indirection in
how you configure your netsync permission hooks and sync patterns. 
The next level was using a community key to sign both user/server
identities and branch identities, blessing them into the community and
allowing a level of delegation as well as just indirection - this is
the part that would fit in the policy space now for that
delegation.  It's also where the concept of a 'branch identity'
finally comes from, which was one place this idea got stuck before.

--
Dan.

pgpRMueSKXTv6.pgp
Description: PGP signature