[Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL

Dirk Meyer dmeyer at tzi.de
Thu Dec 4 10:04:47 UTC 2008


Alexey Melnikov wrote:
> This is quite sensible reminds me of an older IETF effort called
> SACRED (see RFC 3767 and friends).

Hello BEEP :)

Thanks for the pointer, I will take a look at it to see if something
useful for us is in it.

> I've scanned the document and have some quick comments/questions:
>
>> Example 4. Client revokes an X.509 Certificate
>>
>><iq type='get'
>>    from='hamlet at shakespeare.lit/denmark'
>>    id='revoke'>
>>  <revoke xmlns='urn:xmpp:tmp:saslcert'/>
>>    <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
>>      <compromised/>
>>  
>>
> Where is <compromised> defined?

It is part of urn:xmpp:tmp:saslcert (or will be once I write the
schema). The problem is that there are two reason to revoke a
certificate: 

1. A certificate is about to expire. The client uploads a new one and
   revokes the old. The client should stay connected.

2. A device should be removed (e.g. stolen). In that case the
   certificate is compromised and if the device is logged in right now,
   it should be disconnected by the server.

I will write some more doc about this.

> I assume this proposal doesn't prevent use of properly certificates
> signed by a CA, which were not uploaded?

No, it is an addition. I will add that note to the doc.

> I think this XEP-to-be should REQUIRE at least use of TLS integrity
> protection and/or SASL security layer with integrity protection.
> Without that any man-in-the-middle that can inject data into a TCP
> stream can upload arbitrary certificates (for which he/she has the
> private key), so effectively giving himself/herself full access to the
> account.

Oops, yes. I sometimes forget that it is an optional feature. IMHO we
need TLS and SASL as requirement to be sure.

I have an additional question: do you think this is a useful?

Thanks for the feedback,

Dirk

-- 
Having trouble in Windows? Reboot!
Having trouble in Linux? Be root!



More information about the Standards mailing list