On Tue, Jan 23, 2007 at 01:10:30PM +1100, Brian May wrote:
Timothy == Timothy Brownawell Timothy writes:
Timothy You don't identify the key by a human-readable
Timothy name. Instead, you identify it by its hash, and there's a
Timothy users/ section in the policy tree that maps
On Tue, 2007-01-23 at 12:03 +1100, Brian May wrote:
What happens if Bob's access needs to be revoked, not because we don't
trust him anymore, but because we no longer trust his key (e.g. his
laptop was stolen).
Presumably, all signatures before the event can still be trusted, but
new ones
On Tue, Jan 23, 2007 at 12:03:55PM +1100, Brian May wrote:
Nathaniel == Nathaniel J Smith [EMAIL PROTECTED] writes:
Nathaniel Alice and Bob both have access, and then Bob's access
Nathaniel is revoked, and life continues on indefinitely:
Nathaniel +ab
Nathaniel|
Timothy == Timothy Brownawell Timothy writes:
Timothy You don't identify the key by a human-readable
Timothy name. Instead, you identify it by its hash, and there's a
Timothy users/ section in the policy tree that maps the hash to
Timothy something human-readable for UI purposes.
Each revision in the policy branch contains a set of rules, such that
for any particular cert we can look at the rules and decide whether
that cert passes. The tricky question, that has been blocking
progress on policy branches, is how -- given a root revision in the
policy branch -- we find the
On Sat, 2007-01-20 at 03:15 -0800, Nathaniel J. Smith wrote:
[snip snip snip]
Example 3:
+ab
/ \
-b/\-a
/ \
a1 b1
Here we have some sort of determined disagreement between admins.
There isn't much monotone can do except point out the problem, and let
