----- Original Message -----
From: "Peter Saint-Andre" <stpeter at stpeter.im>
Sent: Tuesday, October 27, 2009 10:28 PM
On 10/27/09 4:28 AM, Alexey Melnikov wrote:
Hi Peter,
Peter Saint-Andre wrote:
I had hoped to update draft-saintandre-tls-server-id-check before
the
submission cutoff today, but it's not going to happen because
there's
quite a bit of feedback to sift through (ideally I would have
followed
the list discussions more closely the first time around).
However, I
shall work to update it in the next few days, at which time I
will also
rename it to remove the strings "tls" and "server" since the
scope of
the spec has widened to include non-TLS interactions as well as
client
identity checking. My apologies for the delay.
Without my AD hat: I don't think the document should cover client
identity checking. I found Kurt's arguments to be convincing.
I think that the distinction between application roles and security
roles causes some confusion here. This I-D talks about security
roles,
not application roles. Thus, for example, when two XMPP servers
wish to
establish a TLS-encrypted connection, from the security point of view
the server that initiates the connection is a TLS client whereas the
server that receives the connection is a TLS server (despite the fact
that from an application point of view both of them are XMPP
servers).
My understanding of Kurt's argument is that we can't say much that's
helpful about how a TLS server checks the identity of a TLS client
because the problem is application-specific and the TLS server
doesn't
really have a "reference identity" (an idea of what identity the
client
will assert). At some level, the TLS server knows that it expects the
TLS client to assert a kind of identity (domain name, email address,
XMPP address, etc.) but not necessarily a particular instance of that
kind ("example.com", "foo at example.com", or whatever).
I need to think about this further. I'm sure that re-reading Kurt's
messages will help...
My take is that the only difference is one of number.
A client is 'configured' with a single reference identity, eg by the
user
keying it into a window, which is then used in a comparison with what
is returned in an X.509 certificate.
A server may support more than one client and so may be configured
with more than one reference identity and use any or all of them in a
comparison with what is received in an X.509 certificate eg with SIP,
Netconf, syslog,
....
Of course, a server may not care to check, may not be configured with
anything, in which case the procedures in this I-D are irrelevant
