1This document describes a lightweight SSH Signature format 2that is compatible with SSH keys and wire formats. 3 4At present, only detached and armored signatures are supported. 5 61. Armored format 7 8The Armored SSH signatures consist of a header, a base64 9encoded blob, and a footer. 10 11The header is the string "-----BEGIN SSH SIGNATURE-----" 12followed by a newline. The footer is the string 13"-----END SSH SIGNATURE-----" immediately after a newline. 14 15The header MUST be present at the start of every signature. 16Files containing the signature MUST start with the header. 17Likewise, the footer MUST be present at the end of every 18signature. 19 20The base64 encoded blob SHOULD be broken up by newlines 21every 76 characters. 22 23Example: 24 25-----BEGIN SSH SIGNATURE----- 26U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgJKxoLBJBivUPNTUJUSslQTt2hD 27jozKvHarKeN8uYFqgAAAADZm9vAAAAAAAAAFMAAAALc3NoLWVkMjU1MTkAAABAKNC4IEbt 28Tq0Fb56xhtuE1/lK9H9RZJfON4o6hE9R4ZGFX98gy0+fFJ/1d2/RxnZky0Y7GojwrZkrHT 29FgCqVWAQ== 30-----END SSH SIGNATURE----- 31 322. Blob format 33 34#define MAGIC_PREAMBLE "SSHSIG" 35#define SIG_VERSION 0x01 36 37 byte[6] MAGIC_PREAMBLE 38 uint32 SIG_VERSION 39 string publickey 40 string namespace 41 string reserved 42 string hash_algorithm 43 string signature 44 45The publickey field MUST contain the serialisation of the 46public key used to make the signature using the usual SSH 47encoding rules, i.e RFC4253, RFC5656, 48draft-ietf-curdle-ssh-ed25519-ed448, etc. 49 50Verifiers MUST reject signatures with versions greater than those 51they support. 52 53The purpose of the namespace value is to specify a unambiguous 54interpretation domain for the signature, e.g. file signing. 55This prevents cross-protocol attacks caused by signatures 56intended for one intended domain being accepted in another. 57The namespace value MUST NOT be the empty string. 58 59The reserved value is present to encode future information 60(e.g. tags) into the signature. Implementations should ignore 61the reserved field if it is not empty. 62 63Data to be signed is first hashed with the specified hash_algorithm. 64This is done to limit the amount of data presented to the signature 65operation, which may be of concern if the signing key is held in limited 66or slow hardware or on a remote ssh-agent. The supported hash algorithms 67are "sha256" and "sha512". 68 69The signature itself is made using the SSH signature algorithm and 70encoding rules for the chosen key type. For RSA signatures, the 71signature algorithm must be "rsa-sha2-512" or "rsa-sha2-256" (i.e. 72not the legacy RSA-SHA1 "ssh-rsa"). 73 74This blob is encoded as a string using the RFC4253 encoding 75rules and base64 encoded to form the middle part of the 76armored signature. 77 78 793. Signed Data, of which the signature goes into the blob above 80 81#define MAGIC_PREAMBLE "SSHSIG" 82 83 byte[6] MAGIC_PREAMBLE 84 string namespace 85 string reserved 86 string hash_algorithm 87 string H(message) 88 89The preamble is the six-byte sequence "SSHSIG". It is included to 90ensure that manual signatures can never be confused with any message 91signed during SSH user or host authentication. 92 93The reserved value is present to encode future information 94(e.g. tags) into the signature. Implementations should ignore 95the reserved field if it is not empty. 96 97The data is concatenated and passed to the SSH signing 98function. 99 100$OpenBSD: PROTOCOL.sshsig,v 1.4 2020/08/31 00:17:41 djm Exp $ 101