Hi Jeff, [...]
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.
From the TLS protocol level both occurences of "client" should have been "server", yes.
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?
Exactly.
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".
Yes.
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.
You might split this in such a way that you describe how to get the certificate and reference identifiers first (which is slightly different for client and server) and then the process of validation for a given certificate and a given reference identifiers (which no longer depends on whether a client or a server is doing that). Essentially, that means replacing most occurences of "client" with "verifying entity".
However, I am not sure if this really going to improve readability for anyone that is not looking for xmpp-s2s :-/
philipp _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
