[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
theory-02 comments
Here are some comments on draft-ietf-spki-cert-theory-02.txt; I've
deliberately *not* re-read list traffic nor yet referred closely to
draft-ietf-spki-cert-structure-05.txt, in order to try more closely to
simulate the reading experience of the motivated but otherwise
non-SPKI-specialist reader. I've provided suggested wording tweaks where
possible: material there in [square brackets] is not intended to appear
in a tweaked draft.
Cheers, Stefek
1) Section 4.2.3 Linking SDSI names
===================================
For a "fresh" reader, who reads this Draft as their first introduction
to the SPKI world, diving immediately into the example doesn't strike
me as transparent. I think it's worth expanding the treatment here
a little, as "name chains" are a pretty fundamental SPKI feature, and
leaving the first-time reader to arrive at the concept by induction is
a sub-optimal communication strategy. I 'umbly suggest the following form
of words - to be further refined, edited, expanded as appropriate, and to
come immediately after the "4.2.3" heading:
Names can be linked from one principal's name space to another's. For
example, the SDSI name
(name (hash md5 |+gbUgUltGysNgewRwu/3hQ==|) jim marty diana)
means, informally, "the name 'diana' as used by the person called 'marty'
by the person called 'jim' by the keyholder of the key whose MD5 hash is
+gbUgUltGysNgewRwu/3hQ==". [This may be too person-centric for some to
swallow - after all we're trying to broaden the reader's thinking away
from unnecessarily close ties between keys and personal identities. But
I defend the choice of words as providing an introductory motivation for,
and explanation of, SDSI names.]
To resolve such a chain of linked names, the co-operation of each
successive name-space controller is required. Each such entity can
provide this co-operation ahead of time by issuing a (name, key)
certificate, announcing which SPKI principal - a key or key-hash - that
particular entity associates with a given local name. An example which
should make this processing clear follows. [Then launch into the name
resolution example as given, with the one minor wording change that it
is no longer necessary to state that "SDSI defines a (name, key)
certificate." in the course of the example.]
2) 5.1 5-tuple reduction
========================
Picky time: since the two "intersection" operations are different, we should
distinguish their names. auth-intersection and validity-intersection
seem like the obvious names! This change affects section 5.1, and for
consistency most references to "intersection" in 5.2 and 5.3 are then
clearer if they're changed to "auth-intersection" and "validity-intersection"
in these respective sections.
3) 5.2 <auth> intersection, fourth para:
========================================
This reads:
<tag>s are required not to gain any authorization by appending new
information. As a result, if Ai and Aj are <tag>s and Ai is a prefix
of Aj, then the intersection of Ai and Aj is Aj.
When I read this I was a little unclear as to whether it meant
"auth-intersection mustn't increase privilege", or "<tag> semantics
are constrained by fiat to never denote increased privilege as a result
of appending further elements". On a moment's thought I assume the latter
is meant. If so, I'd suggest wording to make this a little more explicit,
for example:
It is a principle of <tag> construction that authorization cannot be
increased by appending new information to an existing <tag>.
in place of the first sentence.
4) 5.2 <auth> intersection, definition of (*) (sixth para)
==========================================================
This reads:
(*)
represents the set of every possible S-expression. That is, it is an
identity operation for intersection.
Um, if we're playing discrete mathematicians for the moment, (*) isn't
an "identity operation for [auth-]intersection", but rather an "identity
element for auth-intersection". That is, for all auths A,
auth-intersection( A, (*) ) = auth-intersection( (*), A ) = A
i.e. suggestion is to replace "identity operation for intersection" with
"identity element for auth-intersection" for sure, and possibly to include
the further sentence expositing what is meant by an identity element.
5) 5.2 <auth> intersection, definition of (* range) intersection
================================================================
This reads:
(* range <ordering-type> <low-lim>? <high-lim>?)
stands for the set of all byte strings of the given ordering type
(numeric, alphabetic, ...) subject to the given high and low limits.
Low or high limits can be omitted, if one wants to specify a semi-
infinite set.
How would one distinguish low-lim from high-lim, since either may be
ommitted? The structure-05 draft tells you, but in that draft
the upper limit is called <up-lim> not <high-lim>. Suggestion:
at minumum, make this draft use <up-lim> instead of <high-lim>;
more helpfully, also mention that <low-lim> and <up-lim> are
syntactically distinguishable. I.e., suggested rewording of final
sentence (since I don't like "semi-infinite" either) is
Low or high limits - which are syntactically distinguishable -
can be omitted, to specify a range bounded only at one end.
6) 5.3 <validity> intersection, optimisation for online tests (4th para)
========================================================================
This reads:
However, if one wants to have longer-lived reduced 5-tuples, one
might choose to perform the intersection literally for literally
provided date ranges, but to accumulate the union of on-line tests,
to be applied at a later time to the reduced 5-tuple. This is under
the assumption that the date range for an on-line test is a function
of the time at which the test is made.
I find the wording here is less than totally clear. I think the draft
is saying that the obligation to perform the on-line test(s) may be
deferred during tuple reduction, but must have been performed by the
time final tuple reduction (in order to establish the truth or falsity
of whatever predicate the full chain of certs is speaking about) is
required. So, there are at least the following 3 strategies one might
imagine applications using:
- - do-onlines-as-you-go: appropriate when you'll be using the result of
5-tuple reduction immediately, gives you the earliest (but not
necessarily cheapest) notification of failure
- - onlines-at-end: this batches up external comms, allows you perhaps to
fail locally before external lookup, but is still aimed at using the
result of tuple reduction immediately
- - onlines-at-end-as-needed: keep partially-reduced form as a precomputed
partial result, dependant at (expected to be repeated) times of use
only on external lookup - appropriate where you expect to be using a
given cert-chain repeatedly, which has dependencies on at least one
external lookup, whose returned daterange is shorter than the expected
timespan for the local application's repeated usages of the cert chain.
If I've got these cases and the motivations right, it would probably be
worth amending the draft. Since this is the "theory" draft, rather than
elaborating the three cases above and mentioning any other intermediate
ones, it might make more sense to replace the "However, if one wants...
...test is made." para with the following general text:
An application doing 5-tuple reduction is free to perform
validity-intersection in any order it chooses, since
validity-intersection is both associative and commutative. In
particular, it may choose to perform intersection over all
literally provided date ranges before performing any intersections
over date-ranges provided as part of the result of on-line tests,
and may choose to repeat only access to fresh on-line tests when
repeatedly reducing the same collection of 5-tuples.
and leave the description of the 3 cases and the trade-offs between them
to an "implementation hints" section or to another draft.
- --LAA04614.890392354/szaba.hpl.hp.com--
------- End of Forwarded Message
--MAA04805.890395597/szaba.hpl.hp.com--