How should SSHSIG/ssh-keygen handle signatures by a Certificate
paultag at gmail.com
Fri Feb 10 23:05:08 AEDT 2023
On Fri, Feb 10, 2023 at 09:10:04AM +0000, Brian Candler wrote:
> You didn't provide the "-Y sign" commands that you used, but let me
> demonstrate using OpenSSH_9.2p1. For testing I have:
Well, part of that is I didn't use -Y sign :) - from my original email:
> I generated these signatures by hand, I'm not sure how to get
> ssh-keygen to create them yet - although I'm sure it's possible,
> I'm just not a smart man
OK, well, by hand is perhaps unhelpful. I implemented SSHSIG myself
and generated signatures using that implementation.
> In other words, it's a chain. You need to verify it using the CA's
> public key:
> $ echo "brian at +nsrc cert-authority $(cat ca.pub)" >hello.allowed3
I think `cert-authority` is the critical bit I was missing in my
example. When I add that, I get a more interesting error:
$ ssh-keygen -Y verify -I test1 -f principals -n text -s hello.asc < hello
principals:1: certificate not authorized: Certificate invalid: expired
Could not verify signature.
However, when I fix the time:
$ ssh-keygen -Y verify -O verify-time=20230119095200 -I test1 -f principals -n text -s hello.asc < hello
principals:1: certificate not authorized: Certificate invalid: name is not a listed principal
Which is now even more interesting and much closer to what I was
expecting, which is great.
> To summarize, I believe the following is true:
> - to verify a detached signature made using a certificate, you must
> provide the public key of the certificate authority which originally
> signed that certificate
Yeah, I believe this to be true as well -- the missing bit was a typo
excluding 'cert-authority' in my principals file from earlier, which is
plain user error.
> - the time validity of the parent certificate is already being
> verified, without any code patches required
I agree. -O verify-time also works as exected here.
> I guess it might be more user friendly not to allow signing with an
> expired or not-yet-valid certificate, or at least to warn if you do
> Regarding your other question:
> "3. What happens if my principals in the SSHSIG principals file don't match in
> the ssh certificate"
> The answer is the manpage under "ALLOWED SIGNERS":
> When verifying signatures made by certificates, the expected
> principal name must match
> both the principals pattern in the allowed signers file and the
> principals embedded in
> the certificate itself.
I'll admit I also missed this (well, I saw it, but I globbed this into
the ssh certificates principals file for logging into a system rather
than fully internalizing the 'signature' bit there), it's a very helpful
I can confirm this above as well. The expected behavior also happens
when setting valid-before/valid-after in the principals file in addition
to the Certificate, which also makes a great deal of sense.
Right, alright. Sorry for the noise, specifically, `cert-authority` not
being in the test principals file was my downfall here. This helps me a
great deal get back the the original task, which was to clean up the
validation logic in the aforementioned go code.
As usual, it's not a shocker to find corner cases well addressed, I'm
just sorry I didn't spot it sooner.
More information about the openssh-unix-dev