Dirk Meyer wrote:
Alexey Melnikov wrote:
This is quite sensible reminds me of an older IETF effort called
SACRED (see RFC 3767 and friends).
Hello BEEP :)
Indeed :-).
Thanks for the pointer, I will take a look at it to see if something
useful for us is in it.
Good.
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).
Ok. Please also describe purpose of various revocation reasons in prose.
The problem is that there are two reason to revoke a
certificate:
Yes, I understand that having different revocation reasons is important.
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.
Thanks.
