| This document describes a lightweight SSH Signature format |
| that is compatible with SSH keys and wire formats. |
| |
| At present, only detached and armored signatures are supported. |
| |
| 1. Armored format |
| |
| The Armored SSH signatures consist of a header, a base64 |
| encoded blob, and a footer. |
| |
| The header is the string “-----BEGIN SSH SIGNATURE-----” |
| followed by a newline. The footer is the string |
| “-----END SSH SIGNATURE-----” immediately after a newline. |
| |
| The header MUST be present at the start of every signature. |
| Files containing the signature MUST start with the header. |
| Likewise, the footer MUST be present at the end of every |
| signature. |
| |
| The base64 encoded blob SHOULD be broken up by newlines |
| every 76 characters. |
| |
| Example: |
| |
| -----BEGIN SSH SIGNATURE----- |
| U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgJKxoLBJBivUPNTUJUSslQTt2hD |
| jozKvHarKeN8uYFqgAAAADZm9vAAAAAAAAAFMAAAALc3NoLWVkMjU1MTkAAABAKNC4IEbt |
| Tq0Fb56xhtuE1/lK9H9RZJfON4o6hE9R4ZGFX98gy0+fFJ/1d2/RxnZky0Y7GojwrZkrHT |
| FgCqVWAQ== |
| -----END SSH SIGNATURE----- |
| |
| 2. Blob format |
| |
| #define MAGIC_PREAMBLE "SSHSIG" |
| #define SIG_VERSION 0x01 |
| |
| byte[6] MAGIC_PREAMBLE |
| uint32 SIG_VERSION |
| string publickey |
| string namespace |
| string reserved |
| string hash_algorithm |
| string signature |
| |
| The publickey field MUST contain the serialisation of the |
| public key used to make the signature using the usual SSH |
| encoding rules, i.e RFC4253, RFC5656, |
| draft-ietf-curdle-ssh-ed25519-ed448, etc. |
| |
| Verifiers MUST reject signatures with versions greater than those |
| they support. |
| |
| The purpose of the namespace value is to specify a unambiguous |
| interpretation domain for the signature, e.g. file signing. |
| This prevents cross-protocol attacks caused by signatures |
| intended for one intended domain being accepted in another. |
| The namespace value MUST NOT be the empty string. |
| |
| The reserved value is present to encode future information |
| (e.g. tags) into the signature. Implementations should ignore |
| the reserved field if it is not empty. |
| |
| Data to be signed is first hashed with the specified hash_algorithm. |
| This is done to limit the amount of data presented to the signature |
| operation, which may be of concern if the signing key is held in limited |
| or slow hardware or on a remote ssh-agent. The supported hash algorithms |
| are "sha256" and "sha512". |
| |
| The signature itself is made using the SSH signature algorithm and |
| encoding rules for the chosen key type. For RSA signatures, the |
| signature algorithm must be "rsa-sha2-512" or "rsa-sha2-256" (i.e. |
| not the legacy RSA-SHA1 "ssh-rsa"). |
| |
| This blob is encoded as a string using the RFC4243 encoding |
| rules and base64 encoded to form the middle part of the |
| armored signature. |
| |
| |
| 3. Signed Data, of which the signature goes into the blob above |
| |
| #define MAGIC_PREAMBLE "SSHSIG" |
| |
| byte[6] MAGIC_PREAMBLE |
| string namespace |
| string reserved |
| string hash_algorithm |
| string H(message) |
| |
| 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. |
| |
| The reserved value is present to encode future information |
| (e.g. tags) into the signature. Implementations should ignore |
| the reserved field if it is not empty. |
| |
| The data is concatenated and passed to the SSH signing |
| function. |
| |