[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Drastic SPKI simplifications
-----BEGIN PGP SIGNED MESSAGE-----
[I meant to send a reply to this from my LINUX system, but I don't see that
reply in my mailbox. If this is a duplication of that, please excuse me.]
At 04:50 PM 8/28/97 GMT, William Allen Simpson wrote:
>My latest drastic simplification proposal is that we describe a 2-tuple,
>3-tuple and 4-tuple, in the following order:
>
>[ Issuer, Assertion ]
>
> - makes assertions about self.
Assertions about self are rare enough not to bother with a special form.
The idea of using parameter ordering so that we always lop off the end one
is fine, but if you want to start with a 2-tuple, start with the ACL entry:
[ Target, Assertion ]
and growing it to
[Target,Assertion,Issuer,Propagation,Validity]
>One of the confusions that I've had with the current 5-tuple terminology
>is the use of "Subject". I keep thinking of the Subject as principal
>actor, and the Assertions as verbs (actions).
>
>Actually, the principal actor is the Issuer, the Assertions are more
>like combined adjectives, adverbs and subordinate clauses, and they all
>act upon the Subject.
>
>Therefore, I propose we change the term from Subject to Target.
We could debate terms endlessly. I chose Subject because it was a standard
term in the field, thanks to X.509.
I think Target is a good term, too, but I really don't want to get into
a long debate over names (again).
If I hear a groundswell of support for some name change, I'll change it, but
let's not spend too much time on it. The same goes for Assertion vs <auth>
vs (tag). This seems to be a matter of taste. We settled on (tag) because
it was neutral.
>====
>
>I also recently noted that Validation is optional, and not required in
>every certificate. If we think of it as a subordinate clause, then it
>too is really part of Assertions, as a positive assertion about a time
>restriction or other action. This brings us down to a 4-tuple.
I assume you mean validity dates rather than "Validation". Validation of
certs is necessary. Validity fields are also necessary, but if you want to
say +/- infinity, you can say that by leaving off the appropriate date. If
you want no online test, you leave it off. This doesn't mean that we can
just drop all three from all certs.
Yes -- tag, propagate and the 3 validity limits are like <auth>s and might
be merged into one <auth> BNF, but I don't think that's a simplification.
It just moves the complexity one layer deeper in the parser.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQCVAwUBNAZc61QXJENzYr45AQHZuwP9HKpkGIMluxG3atsAf4o1o1ruVhyDDfXY
tzPnbkMD7jaYufFUKPhgHO3vM/gNBcAaqWoQudwo0AeuVeA2ieCUzef/NcgR5bGB
+aOvClFm/ThsVEIyMsAyrzPp6/z9XS5CK8v9wn3zI4J/QuMLBz0x2mAW2XNRa6Pg
+xnNrh/8SCg=
=MM2f
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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: