Re: [SPKM] Interoperability

Nicolas Williams wrote:
> 
> On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman wrote:
> > * When will we get a spec out?  How long will the market wait?
> >   Sometimes, you have to accept that the market will deploy something
> >   and you have little influence on it.  In those cases it's better to
> >   write a compelling spec and hope that people will migrate.  Other
> >   times, if you can stretch to meet market timing, you can avoid the
> >   market deploying something that does not meet your spec.  That is
> >   very desirable.
> 
> If we cannot get a spec that will meet our needs in time for the market
> then the proposed protocol could go to Informational and a spec that
> does meet our needs can later go to Proposed-Standard, using a different
> OID.

There is a problem in the traditional (simple) GSS-API and how it is
embedded within several application protocols, that there is no
negotiation of a mechanism (OID).  In real distributed environments,
where a component is both, server and client, a switch to a new
OID might require a "flag day".  Depending on the implementation
(and we know that SPKM is underspecified in this area), an updated
enhanced GSS-API mechanism might use the new OID also in the
generic framing of the exported binary canonical name, and
as a result might not reuse any of the existing ACLs based
on binary canonical names...

The use of the mechanism OID in the generic framing of exported
binary canonical names was (primarily) meant to prevent accidental
collisions of two names from distinct namespaces referring to
distinct entities, not to ultimately require distinct exported
names based on the employed authentication mechanism (although
I admit that some saw this as a potential feature, being able
to distinguish mechanisms of different strength in the ACL).

Personally, I see a real benefit if mechanisms sharing a common
namespace can share ACLs, be that ACLs with printable or
binary canonical names.

-Martin

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm