On Fri, May 20, 2022 at 03:43:43PM +0000, Maik Riechert 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.
>
>
> 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?
That Sig_structure does not match my reading of RFC 8152. The RFC seems
to have Sig_structure to have either 4 or 5 elements, not 6. And there
are context strings other than just "Signature1". The new counter-
signatures draft adds possibility to have 6 element sig_structure.
Nevertheless, any such encoding starts with 0x84, 0x85 or 0x86, which
is not valid user signature in SSH, and would stand for absurd session
id length in authentication signature.
Related would be using SSH keys in JOSE. There the first byte of string
to be signed is 0x65 (part of base64url encoding of '{' (start JSON
object)), which still is not valid in SSH user signature, and still
encodes absurd session id length in authentication signature.
And one thing to watch for in matters like this is that as number of
cryptographic schemes increases, it gets more and more likely that
possibility of harmful interference can not be excluded.
And of course, ssh-keygen can not be used to make the signatures, so
one would need custom code that reads the ssh keys (which may get
nontrivial when dealing with encrypted keys). IIRC, ssh-agent can sign
arbitrary data, so it could be used (I remember long time ago writing
a program that used ssh-agent for non-SSH authentication).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
