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

Drastic SPKI simplifications



I recommend even more extensive simplifications.

Most of the complications appear (to me) to arise from delegations of
authorization, and communicating authorization policy.

While I applaud the fine thinking that has resulted in this amazingly
general approach, now that we have appreciated the scope of
applicability, it is time to focus on the basic fundamentals, with
reference to specific applications.

The problem (as I see it) is that the basic "bare-bones" approach as
documented still requires support for a large amount of extensibility,
even in applications where it would not otherwise be required.

Instead, I recommend the approach that we have used successfully in
other IETF efforts (such as PPP).  The basic processing MUST function
correctly even without implementation support for any extensibility.
This requires careful and focused choices of basic functionality.
Versions would be supported by specific extension tags, rather than
a "version" field.

For my applications (and the reason I joined this effort), I want
something that will be used for both DNS-Sec and PGP.  That is the basic
"bare-bones" focus that (I believe) should guide our choices.

I proposed that the 5-tuple (I,S,D,A,V) be rearranged to (S,I,V,A,D).
There should not be much objection, as this has been rearranged in the
past.  The order is rationalized as follows:

 - Subject first, for easy recognition with database indexing and
   list searching.

 - Issuer second, as it is needed to check validity.

 - Validation third.  There is no need to continue processing when the
   certificate is no longer valid.

 - Assertion (not Authority).  Here is where much of the complexity
   arises.  Only a few basic assertions of "identification" or
   "authorization" are needed for our target applications, and all
   others must be encoded in a fashion that can be easily ignored.

 - Delegation (optional), yielding 3-states: "not allowed", "subject",
   "stop-at-key".

For the basic functionality, this can be reduced to a 4-tuple (S,I,V,A).
No support would be required for Delegation, which has already been
limited to a "(propagate)" flag.  But the optional presence of a 5th
field MUST be processed correctly by all verifiers, although it is
frequently ignored.

We need to choose a few default algorithms to use, and ensure that all
others are easily discarded.  I recommend SHA1 and El Gamal.

Everything else should be dropped from the base specification.

While I like K-of-N, as it is very powerful and it is very like PGP
capabilities, never-the-less it is not required for basic operation.
K-of-N can be implemented as a static or configured policy without
propagating that information in the certificates.  It belongs in a
separate specification.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2