Re: WGLC of draft-ietf-xmpp-posh-02

On 10/25/14, 2:41 AM, Philipp Hancke wrote:
> Am 14.10.2014 01:17, schrieb Ben Campbell:
>> (Oops, messed up the authors' address the first time. Apologies for
>> the duplicate.)
>>
>> This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The
>> draft is available at the following URL:
>>
>> http://tools.ietf.org/html/draft-ietf-xmpp-posh-02
>>
>> The WGLC will conclude on 27 October, 2014. Please send your comments
>> to the authors and the XMPP mailing list.
>
> In several places, "Server identity" and "TLS client" are used, e.g.
>  > Server identity checking (see [RFC6125]) involves three different
>  > aspects:
> [...]
>  > a TLS client SHOULD consider the delegation invalid.
>
> I think this is not the "TLS client" but the "POSH client" and the "Peer
> Identity". The main use case is when an xmpp s2s-server uses POSH to
> verify an incoming connection.

Initially I was resistant to your suggestion (preferring something like 
"POSH-aware TLS client"), but I see your point about incoming 
connections so it makes sense to me that we modify the terminology.

> section 5:
>      The TLS client SHOULD perform all POSH retrievals
>      before opening any socket connections to the application
>      protocol server.
> (ed: extra whitespace before that sentence)
>
> SHOULD is too strong here. I see it as a fallback rather and would only
> do POSH when not finding a proper identity. This would mean that
> sometimes, POSH is used without need.
> I suspect this makes it easier to use POSH as part of the TLS handshake
> rather than as an application layer check.
>
> This is also not possible for the s2s scenario where POSH may be
> triggered by an incoming
> <db:result>somekeywhichwouldnotbeused</db:result>
> which would happen after <starttls/> and after the TLS handshake itself
> is done.
>
> Should be easy to fix though.

Yes, Matt and I will do some wordsmithing.

Peter