The `AuthorizedKeysFile` directive supports the %h, %U, and %u tokens, but the `RevokedKeys` directive does not. Thus it is possible to grant individual users the ability to add authorized login keys (and indeed this is the default with `.ssh/authorized_keys`), including authorized certificate authorities using the `cert-authority` option, but there is no way to grant them the ability to manage their own lists of revoked keys. This should be fixed by enabling support for the %h, %U, and %u tokens for the `RevokedKeys` directive. See also: https://bugzilla.mindrot.org/show_bug.cgi?id=2328 , which proposes a more powerful but more complicated solution to this issue: allowing `authorized_keys` to specify a revocation list file for each certificate authority key it defines.
Note: Both approaches - this one and the one suggested in https://bugzilla.mindrot.org/show_bug.cgi?id=2328 - offer distinct advantages: * Maintaining separate KRLs for each certificate authority is best-practice and enables fine-grained control (e.g. revoking the signature of a particular key by a particular CA but still allowing that same key to be used if it is also signed by a different authorized CA) * However, not everyone follows best practices, and many users will just want to have one file to append their old/invalid/compromised keys to without having to specify `crl-file="~/.ssh/revoked_keys"` separately for every CA in `authorized_keys` Either option would satisfactorily solve the issue of allowing users to control their own revocations, but the ideal solution would probably be to offer both. Also, if per-user revocation files are supported, it would probably be a good idea to give `RevokedKeys` a suitable default; I suggest `.ssh/revoked_keys`. It seems unwise to enable user-specified CAs by default without offering user-specified revocation.