Re: Document editors

On Thu, Mar 11, 2004 at 11:09:47PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > There's at least some minor things (e.g., we should move the model of
> > channel bindings data from the C-bindings).
> 
> I tell you right away that this might be difficult.
> Any description at the high level will have to fit every conceivable
> language binding or it is misplaced.  Think of programming languages
> that you have never heard of before.  I think the channel bindings
> are at the correct place where they are, because at the C-Bindings
> level they could be discussed in reality.

RFC1964 basically treats the fields of gss_channel_bindings_struct as
integers and octet strings.  So does rfc1964's successor.

This proves it can be done.

> > 
> > And we should clarify the name game issue we were arguing about
> > yesterday, particularly considering that rfc1964 implementations have
> > been canonicalizing the target_name of GSS_Init_sec_context() forever.
> 
> You don't seem to understand.
> 
> This canonicalization has always been a local transformation,
> and it has been required and performed for both gss_compare_name()
> and gss_canonicalize_name() --actually MIT Kerberos did it all
> in gss_import_name() IIRC.
> 
> So the existing implementation hasn't been a problem.

Ah yes, pardon the slip.

> > 
> > Most everything else I do see as either new [optional] optional
> > interfaces (GGF extensions, stackable pseudo-mech framework) or new
> > mechanisms, BCPs and the channel bindings draft.
> 
> Exactly.  All seperate documents, all optional extensions.
> No need to change high level or C-bindings for those.

We'll see when we get there.  I repeat: it's too soon to get into
details.

> > 
> > One thing I think could be added to the base spec (though it might
> > require convincing the GGF folk -- note: let's not argue this _now_; I'm
> > pointing out how the base spec might change) is the GSS_Store_cred()
> > extension, since it fixes a serious gap in the spec.
> 
> No no.  GSS_Store_cred() is likely implementation specific, not even
> mechanism specific.  Show me how you will implement it with Microsoft
> Kerberos.

MS would have to do that.  I don't believe you've read the spec.

> I remind you that GSS-API addresses also mechanisms that live entirely
> in the TCB, and that some TCBs will not give you any kind of control
> about credentials.  That really isn't an abstract/portable concept.

You obviously have not read the spec.

Nico
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]