[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: spki@c2.net*Subject*: theory-02 comments*From*: Stefek Zaba <sjmz@hplb.hpl.hp.com>*Date*: Fri, 20 Mar 1998 11:10:58 +0000*Cc*: Carl Ellison <cme@cybercash.com>*In-Reply-To*: Your message of "Wed, 11 Mar 1998 00:49:50 EST." <3.0.3.32.19980311004950.00994270@cybercash.com>

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.

**new drafts submitted***From*: Carl Ellison <cme@cybercash.com>

- Prev by Date:
**Re: ietf** - Next by Date:
**theory-02 comments** - Prev by thread:
**new drafts submitted** - Next by thread:
**theory-02 comments** - Index(es):