[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?

Basically, as Curtis said, a name cert is really just a statement
that "principal Y is hereby authorized to use name X in my namespace."
To be more precise, what this really means is that "all authority that
anyone grants to name X in my namespace is hereby delegated to principal Y."
A name cert is an authorization for Y to claim any rights that have been
or will be granted to (name <me> X).

>> 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.  

I don't see how it follows that artificially restricting the expressiveness
of a cert increases clarity.  Forcing you to break up a single conceptual
cert into multiple "actual" certs may make each individual cert slightly
easier to understand, but obscures the big picture.

>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.

Sure, I agree that this may be what I want to do, and if so, I should be
able to do that.  But why should the mechanism force me to do it that way,
if there's no compelling reason to?  If in my mind I consider the three
name assignments and the authorization above to be an atomic unit,
then why should I be required to split them up?  An SPKI cert should
to represent a statement of trust as naturally and concicely as possible,
and to me it seems much simpler to represent the intention as:

(cert (issuer Ka)
      (subject Kb)
      (name "dad")
      (name "Bob")
      (name "Robert Ford")
      (tag (read files)))

...which means that I (principal Ka) authorize principal Kb
to use the names "dad", "Bob", and "Robert Ford" in my namespace,
and to read my files.  It took me a little staring and thinking
to figure out your example above - sure you can do it,
but why needlessly obfuscate a simple statement?
What I "mean" is represented much more clearly and directly
by this one cert than by the four certs you proposed.

In a way this is just a matter of mechanism versus policy -
SPKI defines a mechanism for expressing trust relationships,
and I think it should avoid expressing policy decisions needlessly.
Now, if there's a real implementation simplicity win or something
in separating name certs from regular certs, that might be an argument -
but restricting the expressiveness just to enforce our own pet policy
doesn't seem like a great idea.  And I'm having a hard time imagining
how separating name certs from regular certs would make implementations
simpler - it seems like it would more likely have the opposite effect,
since now you have to have two different pieces of code to deal with
the two different types of certs, etc.

>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)))

I should have given an example in my orginal message - I can see I was unclear.
What I had in mind was that the (issuer ...) clause would always take a key,
never a name; any name you're assigning would always be in the certificate
body.  So the above cert would be rewritten as:

(cert (issuer Ka)
      (subject Kb)
      (name "Robert Ford")
      (tag (read files)))

And I don't see any ambiguity in that.

Overloading the issuer clause with the name being assigned seems like
fundamentally a rather ambiguous, confusing syntactic kludge anyway.  To
me, the more direct, obvious interpretation of a cert of the form (cert
(issuer (name Ka dad)) ...) is that this is a certificate _issued_by_ Ka's
dad, not a certificate issued by Ka whose purpose is to bind the name
"dad".  That would certainly seem to be the obvious interpretation given
the meaning of the (name ...) form in other contexts.

				Bryan
Follow-Ups: References: