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[1] 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@+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 > this. > > 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 note. 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. Thanks, Brian! paultag -- :wq _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
