Hi Maik,
I don’t know much about ssh, but I read the blog post by Andrew Ayer that you
included.
Are you after something that does what the following line does, but outputs
COSE format?
ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n file file_to_sign
Maybe make modifications to ssh so it can work with the COSE format and still
use the ssh key files?
Nothing wrong with that IMO. It might be useful in some cases to have a command
line that can sign and verify (and encrypt and decrypt) COSE in files. OpenSSL
can do this for the CMS format. I’ve thought about adding this to xclaim.
LL
> On May 20, 2022, at 8:43 AM, Maik Riechert
> <[email protected]> wrote:
>
> Hi all,
>
> A few weeks ago I’ve done some experiments on using SSH keys to sign claims
> using COSE. This was in the context of SCITT which meant that the
> corresponding public key would also have to be published through a DID, and
> that worked fine by converting it to JWK.
>
> I’d like to confirm whether using SSH keys in this context is a sensible
> thing to do, given that SSH keys are also used for user and host
> authentication within the SSH protocol.
>
> OpenSSH added support for “SSH signatures” for arbitrary content in 2019:
> https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig
> <https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig>
>
> SSH signatures are defined in terms of a custom envelope (see 1. and 2.) and
> sig structure (see 3.), which are different from what’s used in the SSH
> protocol.
>
> It says for the signature input:
> “The preamble is the six-byte sequence "SSHSIG". It is included to ensure
> that manual signatures can never be confused with any message signed during
> SSH user or host authentication.”
>
> There is a more detailed analysis of why this preamble is sufficient at:
> https://www.agwa.name/blog/post/ssh_signatures
> <https://www.agwa.name/blog/post/ssh_signatures>
>
> The main insight of that post is that the first three bytes of SSH protocol
> signature input are always zero, and since the first three bytes of SSH
> signatures are always “SSH” it all works out.
>
> The same argument can be made for COSE, here for COSE_Sign1:
>
> The signature input is the CBOR serialization of the Sig_structure array:
> [“Signature1”, body_protected, sign_protected, aad, payload, [signature]]
>
> In hex, the array length is 86, the context string length is 6A, and the
> context string is 5369676E617475726531. This means the first three bytes are
> always 86 6A 53, which is different than zero bytes and also different from
> the SSH signature preamble (“SSH” which is 53 53 34).
>
> Is this a sensible analysis? Anything else to watch out for?
>
> Maik
> _______________________________________________
> COSE mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/cose
> <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
