openssh bugs - Aug 2020 - [Bug 3204] New: Enable user-relative revoked keys files

https://bugzilla.mindrot.org/show_bug.cgi?id=3204

            Bug ID: 3204
           Summary: Enable user-relative revoked keys files
           Product: Portable OpenSSH
           Version: 8.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: macdjord at gmail.com

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3204

--- Comment #1 from Jordan Macdonald <macdjord at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3204

Jordan Macdonald <macdjord at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.mindrot.or
                   |                            |g/show_bug.cgi?id=2328
                 CC|                            |macdjord at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3204

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
So the problem here is that RevokedKeys is a critical option, i.e. if
it is specified then the file must exist and parse successfully.

Enabling per-user revoked keys by reusing the same option but adding
~/, implicit home directories and/or %tokens wouldn't let us retain
this property as not every path expansion will have a krl present.
> 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)
All this is achievable in authorized_keys. To revoke a specific
signature, @revoked the full certificate. To revoke a CA, @revoked the
CA key. To revoke a key, regardless of CA, @revoked its public key.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.