[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on I-D requirement document
At 11:39 AM 4/7/97 -0400, Carl Ellison wrote:
>>I'm going to leave X.509 to its fate; as a standard
>>its already done its political job, for my purposes.
>Offline, I'd be curious about what you consider X.509's political job.
Ill say this online as its useful.
Thanks, firstly, for your discussion in response to my comments. There
is an essential spectrum in telecommunications design between 100% peer-peer
and 100% third-party mediation. As key distribution merges
with telecommunications infrastructures, its necessary to understand
whether a design is at one fixed point, or design to cover
a range. My understanding of SPKI is now that it is a framework,
or something intended to cover a range of possible deployment scenarios.
each environment of use is conforming when it merely uses a SPKI system.
This suggests that for Internet benefit, SPKI will need profiling
so that a common set of mechanisms are mandated as minimally supported.
The documentation form might separate between the semantic framework, and
profile. (The concrete suggestion is that: a list of supported format/type
tags is mandated as a minimum, and a particular reduction algebra
and related auth syntaxes/tags is prepared in the common profile to
support minimum inter operability requirements.) If I understand the SPKI
design correctly, any two parties having established a minimum
inter operability can then proceed to pairwise agree a private
authorization/delegation model using auth types which are not necessarily
On the past:-
The political purpose of first-generation standards is to generate
sufficient market and coverage in the popular implementations such
an industry is born which is not merely a manufacturer of more paper
standards/designs. X.509 has served this purpose; any deployment of
the now 5 on-going design alternatives will have to be more useful, in
the eyes of ordinary users, than the current stuff and project
real value, not religious opinion. This is a useful function
of utilitarian politics.
But to the more relevant future, with less soap:-
In SPKI/SDSI case, I have full faith that real value is now being
created in the authorization model and features.
I do worry that it might be more tempting for some to put the relevant
5-tuple data field(s) in X.509 extension(s), or an S/MIME signedAttribute than
institute a native SPKI/SDSI programming system at all end-points. Its
much easier to hand-off a set of 5-tuples to a SPKI/SDSI interpreter
as a value-add to the existing S/MIME and SSL first-handshake systems than
to change all browsers/UAs to implement the interpreter natively,
particularly if the auth fields are applets in some popular type-safe
programming system such as java.
I suspect we will see a transition to full SDSI/SPKI native adoption.
Programmable signed objects are certainly the way forward, however.
I wonder if we need a new term for SPKI certificate to distinguish
the essence from old-fashioned data-driven designs. Perhaps an SPKI/SDSI
certificate is really a "siglet".