stpeter at stpeter.im
Wed May 11 14:33:14 UTC 2011
On 5/11/11 8:25 AM, Kevin Smith wrote:
> On Wed, May 11, 2011 at 3:24 PM, Kevin Smith <kevin at kismith.co.uk> wrote:
>> On Wed, May 11, 2011 at 2:52 PM, Kevin Smith <kevin at kismith.co.uk> wrote:
>>> On Wed, May 11, 2011 at 2:46 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>> On 5/10/11 6:13 AM, Ralph Meijer wrote:
>>>>> On Tue, 2011-05-10 at 12:18 +0100, Kevin Smith wrote:
>>>>>> 4) Update XEP-0178 (Best Practices for Use of SASL EXTERNAL with
>>>>>> Certificates) with the interim version 1.1rc5
>>>>>> Everyone to vote onlist by 11th May (a fortnight).
>>>> Ralph's is the only position I've seen expressed on XEP-0178. Anyone else?
>>> It's on my TODO for the next hour. I'm just cutting it quite close.
>> "If the certificate contains more than one valid XMPP address that
>> corresponds to a registered account on the server (e.g., because the
>> server offers virtual hosting), then the server SHOULD allow
>> authentication and authorization of the JID specified as the
>> authorization identity in the SASL exchange."
>> I *think* you can read that as saying that if I can provide a cert
>> valid for both alice at wonderland.lit and lostgirl at wonderland.lit, if I
>> specify hatter at wonderland.lit in my authzid, the server SHOULD log me
>> in as hatter. Probably needs clarification that it needs to be an
>> authzid that's present in the cert.
> This is an existing block of text, I think, so this comment probably
> shouldn't block publication of the new version, but it should be
Another good catch. I suggest the following adjusted wording:
If the certificate contains more than one valid XMPP address that
corresponds to a registered account on the server (e.g., because the
server offers virtual hosting) and during the SASL exchange the client
specified an authorization identity that corresponds to one of the JIDs
presented in the client certificate, then the server SHOULD allow
authentication and authorization of the JID specified as the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Council