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='[EMAIL PROTECTED]/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!
