[xmpp] Clarification of TLS Identity checking in draft-ietf-xmpp-3920bis

[Stef Walter <[e-mail]>]

draft-ietf-xmpp-3920bis [1] refers to
draft-saintandre-tls-server-id-check [2] when it comes to TLS
certificate identity verification.

It appears to me that draft-ietf-xmpp-3920bis section 13.7.2.1 (and
possibly section 13.7.2.2) require further clarifications when it comes
to the reference identifiers that are to be used. The draft currently
specifies that the 'to' and 'from' attributes of the initial stream
header become reference identifiers used in certificate verification.

 1. What kind of reference identifiers are defined in section
    13.7.2.1. It seems that the 'to' attribute on the client side of
    a client-to-server connection should be used as two reference
    identifiers of type DNS-ID and CN-ID. If so, this should probably
    be noted specifically.

    It appears that the 'from' attribute used as an identity on the
    server side of a client-to-server connection, is used as a
    XmppAddr. Are there other ways to map this to a reference
    identifier? In either case, this should be noted.

 2. Section 3.2.3 'When Not to Use SRV' says that when a FQDN is
    explicitly configured it should be used in place of SRV lookups.
    It is not clear whether this explicitly specified FQDN should be
    used as a reference identity when verifying a certificate identity.

    This is explicitly user selected or configured information and
    therefore is available to be used as input to build the list of
    reference identifiers.

    A real example of this often occurs with the Google Apps hosted
    XMPP servers. The users explicitly configure the server as
    talk.google.com [3].

    Should the explicitly configured FQDN be used in place of the
    section 13.7.2.1 XMPP reference identifier(s), or in addition to
    them? Either way, this should be clear in the spec.

    Using multiple reference identifiers of the same type is not
    forbidden by draft-saintandre-tls-server-id-check. So this
    alternative shouldn't be dismissed out of hand.

Thanks for considering these issues (or helping set me straight :)

Cheers,

Stef

[1] http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-22

[2] http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14

[3] http://www.google.com/support/a/bin/answer.py?answer=49147