On 4 Nov 2016, at 16:30, Thomas C. Schmidt wrote:
Hi Ben,
please see inline.
On 03.11.2016 22:42, Ben Campbell wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I have a one set of substantive comments/questions, and some
editorial
comments:
Substantive:
- I'm confused about the validation procedure. In step one, is this
the
user name of the user attempting to write the resource? In step 5,
I
do
not understand how this terminates. Which ACL item is the
"previously
selected" one. If that refers to the one selected in the last
iteration
of steps 3 and 4, how do you know there are not more ACL items to
iterate
through?
You are referring to 6.3 "validating writ access"?
In this case, you receive a store request along with a certificate.
In
step 1, you resolve the user name of the requester, i.e., the user
name that corresponds to the certificate in the request.
Adding something to the effect of "This is the user requesting the
write
operation" would be helpful.
O.K., done.
... then you identify the user in the ACL and walk up the
delegation
chain.
In step 5, you have arrived at the root of the delegation tree. This
is the case, when the to_user equals the signer equals the owner of
the resources (see see Figure 1). This is also how it terminates -
the
owner of the resource is the root of the trust chain.
I'm probably being dense here, but my confusion is in the phrasing of
"the "to_user" value user name of the signer of the previously
selected
ACL item". Won't that always be true for every ACL item up the chain
after the first?
No, the selected ACL item from the previous step is the row you are
in. It basically says that the "to_user" value equals the username of
the signer. This is the "A A" case in row 4 in your example below.
This row should be in an ACL only once and the user must be the owner
of the resource, which is requested to be verified separately.
As an example, Lets say I have a delegation chain of A,B,C,D, where A
is
the owner. Would the ACL chain look like the following (in
leave-to-root
order )?
signer to_user
1 C D
2 B C
3 A B
4 A A
If so, then ACL 2 seems to have a to_user that matches the signer of
ACL
1 (the previously selected ACL), which seems to terminate early.
Again, I'm sure I'm missing something.
I believe the confusion comes from the "previously" - this is meant to
refer to the "previous step" and the actual row. We changed
"previously" to "previous step" to avoid this confusion.
I still think I'm confused. Step 5 basically says iterate over steps 3
and 4. If I'm currently looking at the ACL from the Nth iteration of 3
and 4, it seems to me that the "ACL from the previous step" is ACL N-1.
If the terminal condition is when you find an ACL where the signer and
the to_user are the same, then I you could say _that_ without getting
into "previous steps."
[...]
-- 2nd paragraph from end: The MUST seems more like a statement of
fact.
(E.g. "The resulting ... integer is used...")
Mhmm, I don't think so. These are all iterative decision steps: try
(a), then write ... otherwise try (b), then write ... +++ ...
otherwise refuse.
That was a cut and paste error on my part--I meant the 2nd to last
paragraph of 3.1.
... still there it says: Do 1.-3. to obtain an integer, and then use
exactly this (and no other). This sounds to me like a normative MUST??
Okay. ( That is, I still don't think it's necessary, but it also does
no harm, so I'll withdraw that concern.)
Thanks!
Ben.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
