On Tue, Apr 03, 2007 at 03:02:56PM +0300, Miika Komu wrote:
> http
://www.iki.fi/miika/docs/btns-api-ietf68.pdf
BTW, channel bindings are best thought of as a property of
pTokens, not
iTokens.
Unique channel bindings (e.g., if we go the SKEYSEED route)
can only be
associated with specific channel instances, whereas
end-point channel
bindings can be associated with either the channel or the
end-point
identities. Also, we need to apply a small transformation
to the
end-point public keys in order to produce a channel binding
octet string
(see other posts from Julien, Michael). Therefore it's best
to always
think of channel bindings as an attribute of a channel.
Also, a peer identity (iToken) might have multiple names
(though only
one asserted name); its asserted name will never be a public
key unless
the peer is a BTNS peer.
We do, however, want the peer public keys, if there are any,
to be
available through the iToken.
Recap:
channel binding octet string -> attribute of
pToken
end-point public keys values -> attribute of
iToken
Nico
--
_______________________________________________
|