How should SSHSIG/ssh-keygen handle signatures by a Certificate

[Paul Tagliamonte]

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 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
>    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