On Tue, 09 Nov 2010, PeterSA replied: > > On 11/6/10 5:33 AM, =JeffH wrote: >> >> 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. > > You're right. I've scrubbed mention of "TLS client" from that paragraph: > > Note: In some application protocols that support server-to-server > communication (e.g., XMPP), the procedure described in this > section can be performed by an application server acting when > verifying an incoming server-to-server connection, not only by an > application client when verifying the server with which it is > interacting to establish an outgoing client-to-server connection. > In this case, the application server verifies the identity of the > peer server that is attempting to connect and uses as its > reference identifier the DNS domain name asserted by the peer > server (e.g., as triggered by a request to send a message from an > entity associated with the peer server to an entity associated > with the application service). Other than the source of the > reference identifier and the reversal of roles, the verification > process remains unchanged.
great, thx, that works for me and seems much clearer. >> 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? > > Yes. good, we're on same page. >> 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". > > By "service" here we're talking about an application service, not a TLS > server. In the server-to-server scenario, we're talking about one > application service verifying the identity of a peer service. Ok. >> 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. > > I don't particularly want to do a lot of refactoring on this I-D to > incorporate the server-to-server case. Perhaps this note belongs in > documents that re-use the server-id-check methodology -- e.g., we could > add it to draft-ietf-xmpp-3920bis for the XMPP case. Ok, good idea. >> 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). > > I think that's out of scope for this I-D, and we already say so in > Section 1.4.2. ah ha, yes, you're correct, nevermind. thanks, =JeffH _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
