anyone using certificates with an empty principals section?

[Ethan Heilman]

In case anyone runs into this issue, I figured out a workaround to still
get wildcard-like functionality working for  AuthorizedKeysCommand in
OpenSSH 10.3/10.3p1. https://github.com/openpubkey/opkssh/pull/513

I set a dummy principal like "opkssh-wildcard" in the SSH cert and then
AuthorizedKeysCommand responds with:
`cert-authority,principals="opkssh-wildcard" <ca-key>`, if and only if, the
certificate passes the policy check performed by AuthorizedKeysCommand.

Alternatively I could have set the principal to the user's identity, "
alice at example.com", rather than the desired username, "root' and just have
AuthorizedKeysCommand list the principals supplied in the SSH cert in its
output. As far as I can tell this seems to fit the original intent of the
principal in SSH certificates.




On Wed, Apr 8, 2026 at 2:53 PM Ethan Heilman <eth3rs at gmail.com> wrote:

> Hi Damien/mailinglist
>
> I am a little late to the party, having missed when this email was
> originally posted.
>
> OPKSSH ( https://github.com/openpubkey/opkssh/ )  relies on the wildcard
> behavior of the empty principal in user SSH certificates.
>
> OPKSSH:
> 1. Issues a user an SSH certificate containing user identity attestations
> about the user.
> 2. User sshes as a particular principal with the SSH certificate. The SSH
> certificate is sent to an AuthorizedKeysCommand that reads identity
> attestations along with the desired principal from the SSH session and
> checks if OPKSSH policy allows that identity to assume that principal.
>
> Because we don't know the desired principal at ssh certificate issuance
> time and the user may use the certificate for multiple principals, we must
> rely on the principal flag being empty as a wildcard.
>
> Would this impact SSH user certificates processed via
> AuthorizedKeysCommand? I doubting I am the only project depending on this
> functionality for access time policy evaluations of SSH certificates.
>
> Thanks,
> Ethan
>
> On Wed, Apr 8, 2026 at 2:24 PM Ethan Heilman <eth3rs at gmail.com> wrote:
>
>> Hi Damien,
>>
>> I am a little late to the party, having missed when this email was
>> originally posted.
>>
>> OPKSSH ( https://github.com/openpubkey/opkssh/ )  relies on the wildcard
>> behavior of the empty principal in user SSH certificates.
>>
>> OPKSSH:
>> 1. Issues a user an SSH certificate containing user identity attestations
>> about the user.
>> 2. User sshes as a particular principal with the SSH certificate. The SSH
>> certificate is sent to an AuthorizedKeysCommand that reads identity
>> attestations along with the desired principal from the SSH session and
>> checks if OPKSSH policy allows that identity to assume that principal.
>>
>> Because we don't know the desired principal at ssh certificate issuance
>> time and the user may use the certificate for multiple principals, we must
>> rely on the principal flag being empty as a wildcard.
>>
>> Would this impact SSH user certificates sent via  AuthorizedKeysCommand?
>> I doubt I am the only project depending on this functionality for using
>> access time policy evaluations of SSH certificates.
>>
>> Thanks,
>> Ethan
>>
>>
>>