RRC and sign_only
jhutz at cmu.edu
Thu Dec 18 03:19:55 EST 2008
--On Wednesday, December 17, 2008 07:54:21 PM -0500 Greg Hudson
<ghudson at mit.edu> wrote:
> On Wed, 2008-12-17 at 19:09 -0500, Jeffrey Hutzelman wrote:
>> I have to agree with Love here. Essentially what you're saying is that
>> if you use this API, it might not interoperate, because it cannot
>> successfully decode anything that an RFC4121 implementation might send.
> If you are decoding an RFC4121 message, you will use the API in stream
> mode (or just use the non-iov API).
> I'm not sure you're understanding the situation at hand here (although I
> believe Love is), so I'm struggling to find a good analogy. If the wire
> format were XML, then you might imagine an analagous API which can be
> used in two modes:
I'm afraid the analogy was not terribly useful to me; I don't know much
about XML, but have a pretty good understanding of how RFC4121 works.
However, I think I see where I went wrong. For some reason I thought we
were talking about the GSS-API layer interface, and I'm firmly convinced
that at that layer, all interfaces which accept GSS-API per-message tokens
must be able to process any valid token.
It's now clear to me that Sam was talking about the lower-layer crypto API,
and at that layer, I agree it's entirely reasonable for some cases not to
support arbitrary RRC. It's OK that some interfaces are not useful in
constructing an RFC4121 implementation.
More information about the krbdev