Maik Riechert <[email protected]> wrote: > 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.
In most cases, SSH keys are just raw public keys in a particular format.
I'm not sure I understand what value there is in using that specific wrapping.
Often the underlying keys (public and private) are identical, with just
slightly different file wrappings.
> 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?
I'm not sure what your goals are.
I agree that "SSH signatures" are not COSE signatures, but how does this help
the world?
Seeing that you've CC'ed SCITT, I wonder if you are thinking that using SSH
keys would allow for more natural management for developers?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
