Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security)
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 s
Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security)
Hi, Daniel Carosone wrote: > That's kind of my point about the separate date certs we have > currently. You propose a mechanism whereby an out-of-order or > future-dated date cert would be considered invalid and untrusted -- > instead of now where it's trusted but essentially ignored (other than > for display and as a selector target). It doesn't seem like much > benefit, which is why I think it only becomes interesting when we're > looking at signing-dates on certs that make other kinds of statements > (like asserting branch membership). 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. > I could attach a special netsync-instruction type of cert that says > "don't send until date X", or I could attach a branch cert that says > "add to branch Y after date X" (and then rely on netsync branch > pattern selection. In practice and in general, I don't think this > really cuts it as a solution. In particular, I probably do want to > 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, IMO. :-( > To me, a better use for "valid-from" might be on testresults and job > scheduling. Say I want to automatically build downloadable snapshots > for multiple architectures of the most recent revision to have passed > a set of tests, but the scheduling of when during the day to start the > build depends on some complex pattern that I can't easily represent in > the multiple platform's scheduling tool. So, I make the build depend > on a summary test cert, that passes if all the other prerequisite > tests pass. As those test certs come in, I issue summary test certs > for revs during the day that have passed the set - and I future-date > them for the time this evening that the build should start. The build > slaves just check on a basic interval for new work. When the cert > 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. > 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. > 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). > Or another: maybe I'm doing a ZipperMerge, with an explicitly-named > intermediate zipper branch in the middle; perhaps I expect to take a > day or two to progress through the merge. In any case, it's really > only the last few zipper merge certs that I care about - the current > central head, and whichever left or right node I next want to bring > in. I could set these certs to expire quickly, and hold off syncing > 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. > [*] 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? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security)
On Mon, Oct 20, 2008 at 10:31:32AM +0200, Markus Wanner wrote: > > In particular, my concern is that despite agreeing and acknowleding > > that there can't be a global clock, warnings or errors like this help > > to encourage in the users' minds that there is a global clock anyway. > > Can we really get rid of that at all? If you continue this line of > thinking, why do we have date certs at all? AFAICT it's just for users > convenience so far. That's kind of my point about the separate date certs we have currently. You propose a mechanism whereby an out-of-order or future-dated date cert would be considered invalid and untrusted -- instead of now where it's trusted but essentially ignored (other than for display and as a selector target). It doesn't seem like much benefit, which is why I think it only becomes interesting when we're looking at signing-dates on certs that make other kinds of statements (like asserting branch membership). > > However, if something > > like that does turn out to be legitimately useful, my opinion is that > > it should be via explicit valid-from and valid-until (optional) cert > > fields, rather than by trying to overload the signing date. > > Hm.. interesting use case. I fail to see a use case for a limit with > "valid-until", yet, so let's discuss the "valid-from" thing first. > > I've already encountered situations, where I wanted to postpone > publication of a revision. Signing with a "valid-from" in the future > could possibly solve this, yes. But that would benefit from the very > same date checking, because descendant revisions must be valid from an > even later point in the future. Otherwise you'd suddenly make your > revision appear, just because it's descendant's cert is already valid. Indeed. This is one use-case I've encountered a few times, but I have a feeling that this mechanism isn't quite right as a solution. The basic assumption is that I have a development line I want to keep "private" for some time until it is ready for wider circulation. I could attach a special netsync-instruction type of cert that says "don't send until date X", or I could attach a branch cert that says "add to branch Y after date X" (and then rely on netsync branch pattern selection. In practice and in general, I don't think this really cuts it as a solution. In particular, I probably do want to 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. To me, a better use for "valid-from" might be on testresults and job scheduling. Say I want to automatically build downloadable snapshots for multiple architectures of the most recent revision to have passed a set of tests, but the scheduling of when during the day to start the build depends on some complex pattern that I can't easily represent in the multiple platform's scheduling tool. So, I make the build depend on a summary test cert, that passes if all the other prerequisite tests pass. As those test certs come in, I issue summary test certs for revs during the day that have passed the set - and I future-date them for the time this evening that the build should start. The build slaves just check on a basic interval for new work. When the cert 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. 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. 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. Or another: maybe I'm doing a ZipperMerge, with an explicitly-named intermediate zipper branch in the middle; perhaps I expect to take a day or two to progress through the merge. In any case, it's really only the last few zipper merge certs that I care about - the current central head, and whichever left or right node I next want to bring in. I could set these certs to expire quickly, and hold off syncing until then - if expired certs aren't sent via netsync, they no longer need to be passed around the rest of the world. -- Dan. [*] 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.. pgpIz0l6JyP1P.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: hypothetical - future-dated certs (Re: Monotone Security)
Hi, Daniel Carosone wrote: > I'm not so sure.. I'd happily go for 'strange' or some other word, > rather than 'wrong'. At the very least, I'd like to try and work > through all the cases we can think of where this might arise, and just > confirm whether a sensible or legitimate interpretation could have > been intended. If we fail to come up with any, fine. If we do, > perhaps we'll have a new and interesting use case to consider > supporting properly.. Okay, let's see... > The question remains, however: when something like this is detected, > what should either the user or the software do to resolve the issue? That's the question, yes. > Let's say I decide to add another date cert with a more reasonable > value; this doesn't and can't get rid of the old one, so nothing is > really solved. True. You'd need to explicitly distrust the old cert. > In particular, my concern is that despite agreeing and acknowleding > that there can't be a global clock, warnings or errors like this help > to encourage in the users' minds that there is a global clock anyway. Can we really get rid of that at all? If you continue this line of thinking, why do we have date certs at all? AFAICT it's just for users convenience so far. > I worry that this will just lead to confusion, rather than encouraging > users to fully embrace the realities of the distributed/disconnected > world. I don't think that's feasible. Users will always (want to) express themselves in "normal" dates and times. Otherwise you would have to encourage time definitions like: "before rev foo as signed by bar". > Again, fully support this, just not sure how it should be used. > Giving room to experiment and discover how it should be used is a good > end in itself. Good, I'm glad. ;-) I already have some code to compare dates, I'm thinking about adding that to "mtn db check" or something (as soon as I get time to clean up my spaghetti code...). > It seems to me to be a much more relevant thing to consider as part of > cert format rewrites, when we add a signing-date to certs, and that it > should be applied to the signing-date rather than the basic date. At > that point, signing a cert with a future date *could* be used to delay > the validity of a cert until some future date. However, if something > like that does turn out to be legitimately useful, my opinion is that > it should be via explicit valid-from and valid-until (optional) cert > fields, rather than by trying to overload the signing date. Hm.. interesting use case. I fail to see a use case for a limit with "valid-until", yet, so let's discuss the "valid-from" thing first. I've already encountered situations, where I wanted to postpone publication of a revision. Signing with a "valid-from" in the future could possibly solve this, yes. But that would benefit from the very same date checking, because descendant revisions must be valid from an even later point in the future. Otherwise you'd suddenly make your revision appear, just because it's descendant's cert is already valid. So AFAICT such a feature would even *require* proper timestamp checking. Otherwise you could not enforce such restrictions. Or put another way: as soon as we start to use the timestamps for more than just users convenience, we have to check and validate this information better. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
