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