10cbfa66cSDaniel FojtThis document describes a lightweight SSH Signature format 20cbfa66cSDaniel Fojtthat is compatible with SSH keys and wire formats. 30cbfa66cSDaniel Fojt 40cbfa66cSDaniel FojtAt present, only detached and armored signatures are supported. 50cbfa66cSDaniel Fojt 60cbfa66cSDaniel Fojt1. Armored format 70cbfa66cSDaniel Fojt 80cbfa66cSDaniel FojtThe Armored SSH signatures consist of a header, a base64 90cbfa66cSDaniel Fojtencoded blob, and a footer. 100cbfa66cSDaniel Fojt 110cbfa66cSDaniel FojtThe header is the string "-----BEGIN SSH SIGNATURE-----" 120cbfa66cSDaniel Fojtfollowed by a newline. The footer is the string 130cbfa66cSDaniel Fojt"-----END SSH SIGNATURE-----" immediately after a newline. 140cbfa66cSDaniel Fojt 150cbfa66cSDaniel FojtThe header MUST be present at the start of every signature. 160cbfa66cSDaniel FojtFiles containing the signature MUST start with the header. 170cbfa66cSDaniel FojtLikewise, the footer MUST be present at the end of every 180cbfa66cSDaniel Fojtsignature. 190cbfa66cSDaniel Fojt 200cbfa66cSDaniel FojtThe base64 encoded blob SHOULD be broken up by newlines 210cbfa66cSDaniel Fojtevery 76 characters. 220cbfa66cSDaniel Fojt 230cbfa66cSDaniel FojtExample: 240cbfa66cSDaniel Fojt 250cbfa66cSDaniel Fojt-----BEGIN SSH SIGNATURE----- 260cbfa66cSDaniel FojtU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgJKxoLBJBivUPNTUJUSslQTt2hD 270cbfa66cSDaniel FojtjozKvHarKeN8uYFqgAAAADZm9vAAAAAAAAAFMAAAALc3NoLWVkMjU1MTkAAABAKNC4IEbt 280cbfa66cSDaniel FojtTq0Fb56xhtuE1/lK9H9RZJfON4o6hE9R4ZGFX98gy0+fFJ/1d2/RxnZky0Y7GojwrZkrHT 290cbfa66cSDaniel FojtFgCqVWAQ== 300cbfa66cSDaniel Fojt-----END SSH SIGNATURE----- 310cbfa66cSDaniel Fojt 320cbfa66cSDaniel Fojt2. Blob format 330cbfa66cSDaniel Fojt 340cbfa66cSDaniel Fojt#define MAGIC_PREAMBLE "SSHSIG" 350cbfa66cSDaniel Fojt#define SIG_VERSION 0x01 360cbfa66cSDaniel Fojt 370cbfa66cSDaniel Fojt byte[6] MAGIC_PREAMBLE 380cbfa66cSDaniel Fojt uint32 SIG_VERSION 390cbfa66cSDaniel Fojt string publickey 400cbfa66cSDaniel Fojt string namespace 410cbfa66cSDaniel Fojt string reserved 420cbfa66cSDaniel Fojt string hash_algorithm 430cbfa66cSDaniel Fojt string signature 440cbfa66cSDaniel Fojt 450cbfa66cSDaniel FojtThe publickey field MUST contain the serialisation of the 460cbfa66cSDaniel Fojtpublic key used to make the signature using the usual SSH 470cbfa66cSDaniel Fojtencoding rules, i.e RFC4253, RFC5656, 480cbfa66cSDaniel Fojtdraft-ietf-curdle-ssh-ed25519-ed448, etc. 490cbfa66cSDaniel Fojt 500cbfa66cSDaniel FojtVerifiers MUST reject signatures with versions greater than those 510cbfa66cSDaniel Fojtthey support. 520cbfa66cSDaniel Fojt 530cbfa66cSDaniel FojtThe purpose of the namespace value is to specify a unambiguous 540cbfa66cSDaniel Fojtinterpretation domain for the signature, e.g. file signing. 550cbfa66cSDaniel FojtThis prevents cross-protocol attacks caused by signatures 560cbfa66cSDaniel Fojtintended for one intended domain being accepted in another. 570cbfa66cSDaniel FojtThe namespace value MUST NOT be the empty string. 580cbfa66cSDaniel Fojt 590cbfa66cSDaniel FojtThe reserved value is present to encode future information 600cbfa66cSDaniel Fojt(e.g. tags) into the signature. Implementations should ignore 610cbfa66cSDaniel Fojtthe reserved field if it is not empty. 620cbfa66cSDaniel Fojt 630cbfa66cSDaniel FojtData to be signed is first hashed with the specified hash_algorithm. 640cbfa66cSDaniel FojtThis is done to limit the amount of data presented to the signature 650cbfa66cSDaniel Fojtoperation, which may be of concern if the signing key is held in limited 660cbfa66cSDaniel Fojtor slow hardware or on a remote ssh-agent. The supported hash algorithms 670cbfa66cSDaniel Fojtare "sha256" and "sha512". 680cbfa66cSDaniel Fojt 690cbfa66cSDaniel FojtThe signature itself is made using the SSH signature algorithm and 700cbfa66cSDaniel Fojtencoding rules for the chosen key type. For RSA signatures, the 710cbfa66cSDaniel Fojtsignature algorithm must be "rsa-sha2-512" or "rsa-sha2-256" (i.e. 720cbfa66cSDaniel Fojtnot the legacy RSA-SHA1 "ssh-rsa"). 730cbfa66cSDaniel Fojt 74*50a69bb5SSascha WildnerThis blob is encoded as a string using the RFC4253 encoding 750cbfa66cSDaniel Fojtrules and base64 encoded to form the middle part of the 760cbfa66cSDaniel Fojtarmored signature. 770cbfa66cSDaniel Fojt 780cbfa66cSDaniel Fojt 790cbfa66cSDaniel Fojt3. Signed Data, of which the signature goes into the blob above 800cbfa66cSDaniel Fojt 810cbfa66cSDaniel Fojt#define MAGIC_PREAMBLE "SSHSIG" 820cbfa66cSDaniel Fojt 830cbfa66cSDaniel Fojt byte[6] MAGIC_PREAMBLE 840cbfa66cSDaniel Fojt string namespace 850cbfa66cSDaniel Fojt string reserved 860cbfa66cSDaniel Fojt string hash_algorithm 870cbfa66cSDaniel Fojt string H(message) 880cbfa66cSDaniel Fojt 890cbfa66cSDaniel FojtThe preamble is the six-byte sequence "SSHSIG". It is included to 900cbfa66cSDaniel Fojtensure that manual signatures can never be confused with any message 910cbfa66cSDaniel Fojtsigned during SSH user or host authentication. 920cbfa66cSDaniel Fojt 930cbfa66cSDaniel FojtThe reserved value is present to encode future information 940cbfa66cSDaniel Fojt(e.g. tags) into the signature. Implementations should ignore 950cbfa66cSDaniel Fojtthe reserved field if it is not empty. 960cbfa66cSDaniel Fojt 970cbfa66cSDaniel FojtThe data is concatenated and passed to the SSH signing 980cbfa66cSDaniel Fojtfunction. 990cbfa66cSDaniel Fojt 100*50a69bb5SSascha Wildner$OpenBSD: PROTOCOL.sshsig,v 1.4 2020/08/31 00:17:41 djm Exp $ 101