[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: k-of-n subjects versus k-of-n tags?
> Is there a really strong reason name certs should be so different from auth
> certs?
> Naming in the SPKI model seems to be just a form of authorization
> anyway (authorization to be referred to under a given name in my
> namespace).
I think I understand that last sentence, but to be sure, can you
explain it a little more?
> But one question I didn't see
> mentioned in my quick scan is why it is necessary or desirable to enforce a
> "one cert, one name" rule, as would be done implitly if the name is in the
> issuer expression. Why shouldn't I be allowed to both define a name (or
> even multiple names) and grant authorizations in a single cert? Say I want
> to place my dad under the three names "dad", "Bob", and "Robert Ford" in my
> namespace, and grant him access to some of my files - should I really have
> to create (and keep track of) four different certs in order to do this,
> even if I would just be assigning the same validity period to all of them
> anyway?
The way I see it is this: forcing certs to have the smallest possible
amount of meaning gives a great deal of clarity. Here, a price of clarity
may be that you have to issue a lot of certs to do what you want.
A world with a lot of very simple certs doesn't bother me at all.
One reason it doesn't bother me is that I believe many certs that People
would issue would need no validity information, because the assertions
they make will always be true.
Let's take your example of your father. To do all of what you describe
above, you could issue these four certs, where Ka is you, and Kb is your
father:
(cert (issuer (name Ka "dad")) (subject (name "Robert Ford")))
(cert (issuer (name Ka "Bob")) (subject (name "Robert Ford")))
(cert (issuer (name Ka "Robert Ford")) (subject Kb))
(cert (issuer Ka) (subject (name Ka "Robert Ford")) (tag (read files)))
The first two certs just make aliases and should need no validity
information - presumably the person you call "dad" and "Bob" will always
be the same person you call "Robert Ford". Once you've issued these
certs, you never have to worry about them again.
The third cert binds "Robert Ford" to your father's key, and the fourth
lets "Robert Ford" read your files. You can assign validity information
to one, the other, or both to get what you want.
And that's the clarity: requiring this separation of duties forces you
to be explicit about what you mean. One cert is you saying nothing
except what your name "Robert Ford" is, and how long you expect the
binding to be valid for, and the other is you saying nothing except
what you authorize your "Robert Ford" to do, and how long you expect
that permission to last for.
> I can see why people often would often want to separate name certs
> from auth certs, but that doesn't automatically imply that the standard
> should require that they always be separated - that just makes things
> cumbersome when it's not what you want. Am I missing something?
The problem is, if one cert did both bind a name and authorize, what
would it mean? Does:
(cert (issuer (name Ka "Robert Ford")) (subject Kb)
(tag (read files)))
mean "Kb can (read files) whenever Ka's "Robert Ford" can (read files)",
or does it mean "Ka's "Robert Ford" is Kb ... and ... Kb can (read files)
whenever Ka's "Robert Ford" can (read files)"?
The distinction is important. If you answer "the first", you can't
have that certificate follow:
(cert (issuer Kc) (name Ka "Robert Ford" "best-friend") (tag (sell tickets)))
in a sequence, since authorization isn't flowing through Ka's "Robert Ford".
If you then answer "the second", to try to address this problem, then
you're selectively ignoring tags when you're reducing chains - which
means that the exact meaning of these "compound certs" changes with
their context.
Thanks for listening,
Matt
--
Matt Fredette
fredette@bbnplanet.com, fredette@mit.edu, fredette@theory.lcs.mit.edu
http://mit.edu/fredette/www
"The first time the Rolling Stones played, three people came."
Follow-Ups:
References: