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 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 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] https://www.ietf.org/mailman/listinfo/cose
