Peter Saint-Andre replied:
>
> Philipp Hancke replied:
>
>> Peter Saint-Andre wrote:
>>>
>>> Note: In some application protocols, the procedure described in
>>> this section can be performed by an application server acting as a
>>> TLS client when verifying a server-to-server connection, not only by
>>
>> s/TLS client/TLS server/
>
> In XMPP at least, if Romeo's personal server (montague.lit) attempts to
> connect to Juliet's personal server (capulet.lit), he asserts to her
> that he is montague.lit and she takes that as her reference identifier.
> Thus her server is acting as a TLS client in relation to the presented
> identifiers in the certificate that Romeo's personal server provides.
> This is what's distinctive about the server-to-server case -- an
> application service is acting as a TLS client.
>
> ...
>
>> I think it is not clear who is verifying
>
> If you try to connect to me, I'm going to verify you -- even if I'm an
> XMPP server.
>
>> (probably because both parties
>> are for xmpp-s2s).
>
> Yes, ideally the verification happens in both directions.
To me, what Peter wrote in the proposed "Note:" is confusing because it is
labeling an entity as a "TLS client" that is not a TLS client in the TLS
protocol sense -- it is playing the TLS server role, and is only behaving as a
"TLS client" would in the sense of verifying the entity at the other end of the
incoming connection.
In this case we ostensibly have the "peer server" -- legitimately acting as a
TLS client -- presenting its certificate during the TLS handshake, and thus the
application service is obliged to perform the same checks on the peer server's
asserted identity, as an actual TLS client performs on asserted app service
identity.
yes?
If so, it seems we're linguistically standing on our heads here trying to
shoehorn the notion of "verification of client identity (by the app service)"
into section 4 "Verification of Service Identity".
I propose that we need to perhaps have a separate section for the former and
figure out how to refactor the more detailed section 4 subsections such that we
don't have to needlessly repeat text.
It also seems we ought to do this in a general fashion such that its applicable
for any TLS server processing an inbound connection where the client elects to
assert its identity (eg by presenting a cert).
=JeffH
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
