openssh unix dev - Jun 2020 - would it be possible to extend TrustedUserCAKeys so that certain keys could not be used to authenticate a particular user?

Wondering if it would make sense to have more granular control of
trustedUserCAkeys?  I have 1 key used to sign root certs, the key is
shortlived, and is rotated daily.  And I have a 2nd key to sign non-
privileged user certs.  The non-privileged certs have a longer validity
period, and the signing keys are not rotated as frequently.  It would
be nice to ensure this second signing key's associated pubkey in
trustedusercakeys is never consulted when a root certificate is
presented, perhaps via some form of blacklisting within the
trustedusercakeys file?  This would provide some assurance that the
theft of the second key could not be used to sign root certificates and
be accepted for the systems I manage.

Mark Christian

i might be misunderstanding the question, but wouldn't something like this
work?

Match Group unprivileged
  TrustedUserCAKeys /etc/ssh/unprivilged_pub_key

Match User root
  TrustedUserCAKeys /etc/ssh/priviledged_pub_key

On Mon, Jun 1, 2020 at 11:36 AM Christian, Mark
<mark.christian at intel.com> wrote:
>
> Wondering if it would make sense to have more granular control of
> trustedUserCAkeys?  I have 1 key used to sign root certs, the key is
> shortlived, and is rotated daily.  And I have a 2nd key to sign non-
> privileged user certs.  The non-privileged certs have a longer validity
> period, and the signing keys are not rotated as frequently.  It would
> be nice to ensure this second signing key's associated pubkey in
> trustedusercakeys is never consulted when a root certificate is
> presented, perhaps via some form of blacklisting within the
> trustedusercakeys file?  This would provide some assurance that the
> theft of the second key could not be used to sign root certificates and
> be accepted for the systems I manage.
>
> Mark Christian
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 2020-06-01 at 11:47 -0700, Peter Moody wrote:
> i might be misunderstanding the question, but wouldn't something like
> this work?
> 
> Match Group unprivileged
>   TrustedUserCAKeys /etc/ssh/unprivilged_pub_key
> 
> Match User root
>   TrustedUserCAKeys /etc/ssh/priviledged_pub_key
Yes, this would work.  Feeling a little sheepish at the moment =).

Thank you,
Mark    

> 
> On Mon, Jun 1, 2020 at 11:36 AM Christian, Mark
> <mark.christian at intel.com> wrote:
> > Wondering if it would make sense to have more granular control of
> > trustedUserCAkeys?  I have 1 key used to sign root certs, the key
> > is
> > shortlived, and is rotated daily.  And I have a 2nd key to sign
> > non-
> > privileged user certs.  The non-privileged certs have a longer
> > validity
> > period, and the signing keys are not rotated as frequently.  It
> > would
> > be nice to ensure this second signing key's associated pubkey in
> > trustedusercakeys is never consulted when a root certificate is
> > presented, perhaps via some form of blacklisting within the
> > trustedusercakeys file?  This would provide some assurance that the
> > theft of the second key could not be used to sign root certificates
> > and
> > be accepted for the systems I manage.
> > 
> > Mark Christian
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev