Hi Laurence,

To clarify, this is not about extending OpenSSH or SSH signatures with COSE 
support. The thread is really just to understand whether using SSH keys with 
COSE signatures (in this case for SCITT) would introduce cross-protocol 
confusion or not, and I think the answer is no.

Maik

From: SCITT <[email protected]> On Behalf Of Laurence Lundblade
Sent: Samstag, 21. Mai 2022 13:31
To: Maik Riechert <[email protected]>
Cc: [email protected]; [email protected]
Subject: [EXTERNAL] Re: [SCITT] [COSE] Using SSH keys for COSE signatures

You don't often get email from 
[email protected]<mailto:[email protected]>. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
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]<mailto:[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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssh%2Fopenssh-portable%2Fblob%2Fmaster%2FPROTOCOL.sshsig&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Ccc2646c20b4345bf585408da3b25c9a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637887331225928060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zi8abQEuOYLse8ymV5DCM62b4%2BZbok3nL6H6xFn2ckM%3D&reserved=0>

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.agwa.name%2Fblog%2Fpost%2Fssh_signatures&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Ccc2646c20b4345bf585408da3b25c9a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637887331225928060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=084ltkyRIJ4nDUsGpb%2BFmSmZGlYRO9M5X0XxfcIYAIg%3D&reserved=0>

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Ccc2646c20b4345bf585408da3b25c9a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637887331225928060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7j1xaXWXxrxqCPFE45JEaGNdga0kA%2FzVlN3UP41Puvo%3D&reserved=0>

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to