Re: Determining a token's mechanism

[Doug Rosenthal <[e-mail]>]

    >>> >The gss_parse_token() routine would be easy to implement, and
    >>> it would >do the right thing for all krb5 tokens.

    Marc> For the record, I was replying to John's question of April
    Marc> 7, which was:

    Marc>     (2) Referring to the SPKM_Parse_token() routine as
    Marc> described in draft-ietf-cat-spkmgss-02.txt, we would like to
    Marc> consider the feasibility of incorporating an equivalent
    Marc> routine within GSS-V2.  Question to implementors: please
    Marc> review the definition of this routine and consider whether
    Marc> its functionality is implementable within your mechanism and
    Marc> code base.

    Marc> My answer to this technical question is still the same, I
    Marc> believe.  However, and this was not part of my original
    Marc> response, I don't believe that SPKM_Parse_token() is a
    Marc> useful function in light of its inherent nonportability, and
    Marc> I'd rather not see it included in the spec.


Not to belabor the issue, but given that the token parsing
functionality is either put in a separate function (aka parse_token)
or done "manually" in a multi-mech glue layer, the former would be
more convenient - as it could be used/called by either a multi-mech
glue layer or a single-mech application (if necessary).  Doesn't seem
like a hard function to implement, and would give application
developers another utility function if they needed it.

Also, is it really non-portable if some implementations simply return
null for some of the function outputs while other implementations
return non-null values?  Isn't this the case for some of the other
GSS functions anyway, depending on the underlying
mechansim/implementation?  (e.g. the _state values returned from
init/accept_sec_context)

- Doug