Review of AEAD Encryption API Project; concluding December 5, 2008

[Sam Hartman]

>>>>> "Love" == Love Hörnquist Åstrand <lha at kth.se> writes:

    Love> Sam, Luke, all,
    >> I believe it now includes enough of the GSS side API for
    >> comments.

    Love> Some more comments,

    Love> iov_count should not be size_t, it should be unsigned
    Love> int. size_t is to describe memory sizes, iov_count is not
    Love> that.

I think this is a style question.  On my C library at least, qsort and
calloc take size_t for their counts, while writev takes int.  I don't
have a strong preference, but in the interest of making changes only
when there is a reason to do so, I'd say we should make this change
only if we get others calling for it.

    Love> I think the iov should be before iov_count in the argument,
    Love> just like in writev()/readv().

Luke?  This makes sense to me.

    Love> What do conf_state do to gss_wrap_iov_length() ?

    Love> How does the consumer know the conf_req_flag/qop_req
    Love> arguments when doing gss_unwrap_iov() ?
These are not arguments to the call to gss_unwrap_iov.  I assume what
you're saying here is how does the unwrapper know what to pass in to
gss_wrap_length_iov?  Luke, do you anticipate that the receiver of a
message would need to call wrap_length?  I'd generally assume they
would either use a stream buffer or would already know the
decomposition.

    Love> How does the consumer know the size of the header when in
    Love> DCE mode, its always header + trailer ?
No, I'd expect that in DCE mode no trailer would be used.
It's my understanding that gss_wrap_iov_length will give you the header size.


    Love> Love