[Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
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
>> from='hamlet at shakespeare.lit/denmark'
>> <revoke xmlns='urn:xmpp:tmp:saslcert'/>
>> <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
> 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
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
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,
Having trouble in Windows? Reboot!
Having trouble in Linux? Be root!
More information about the Standards