[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
common
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
standardized.
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".