Sam,
Thanks for your note. One of the successful models with certs and
PKI we have is the https model. The use case I am putting forth
works along those lines. The caller is the client and the callee
is the server; the server, e.g., a calling card server or a
priority call processing server, authenticates itself first; the
client authentication is optional as DTLS allows and within the
secure tunnel the caller sends DTMF tones as RTP packets to enter
the calling card information or priority codes.
That use case came up in a discussion recently. It is not "future
work" in my opinion. It is also not dramatically different from
what we have been discussing either.
regards,
Lakshminath
On 6/5/2007 4:23 AM, Sam Hartman wrote:
Another thing to consider is that rtpsec is only one model of how the
technology we're developing can be used today. In the future, if
there is interest, we may specify how you can interoperably use certs
in a PKI to get authentication of the media even if you don't have
authentication of the signaling path.
Yes, that looks easy. However it's more complicated than it first
appears. My preference is that we develop one mandatory to implement
architecture for the use case we've been discussing today. We do
future work in the future.
If you want to build a future where you can use something other than
certs in TLS for one of the authentication directions then work with
the TLS community to build that support into TLS.