[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: auth global uniqueness
At 08:52 PM 3/31/97 +0200, Bryce wrote:
>Hm. Forgive me if this is a newbie question that you have
>already all hashed out, but why do we have the random-name
>kludge to ensure "<auth>" name global uniqueness instead of
>saying that the auth name is relative to the issuer?
Good question. We went over it, but probably not in the best detail.
An auth name is relative to the verifier, not the issuer. The verifier
might decide to trust someone else to speak about his brand of <auth> -- and
might delegate that permission to some issuer -- but the source of a
definition is always the left-most edge of a chain and that's the verifier
(also at the right-most edge of a chain, which is why I call them loops).
Back to your original question: I have looked at all the examples I could
find and have not yet found a need for making the <auth> name globally
unique. If there were such a need, we could use the hash of the public key
of the definer to meet it. However, when I looked at that solution, I saw
that we weren't using the public key nature of the public key for this --
only its uniqueness. A random bit string of the same size is just as unique
(or more so, given the structure of RSA). So -- I added the note about a
random nonce to make an <auth> name unique, in case we ever discover a need
for name uniqueness.
As I said, I haven't seen a need for unique <auth> name. For example, if we
have the <auth> of the form:
spend <bank-ID> <account-#> <spending-limit>
it is assumed that the <bank-ID> and <account-#> make what we're talking
about unique. In a sense, there is a combined auth name of the form
{spend<bank><account>} which is unique, for our purposes. If it isn't, we
have a security flaw. We have a more global auth name of the form
{spend<bank>}, of course, which is why we don't just combine the three
items into one byte string (an entity with {spend<bank>} can delegate to
{spend<bank><account>} when the <bank> fields are equal...).
I suspect that this remains true in all cases.
- Carl
+------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+------------------------------------------------------------------+
References: