summaryrefslogtreecommitdiff
path: root/PROTOCOL.sshsig
diff options
context:
space:
mode:
authorColin Watson <cjwatson@debian.org>2019-10-09 22:59:48 +0100
committerColin Watson <cjwatson@debian.org>2019-10-09 22:59:48 +0100
commit4213eec74e74de6310c27a40c3e9759a08a73996 (patch)
treee97a6dcafc6763aea7c804e4e113c2750cb1400d /PROTOCOL.sshsig
parent102062f825fb26a74295a1c089c00c4c4c76b68a (diff)
parentcdf1d0a9f5d18535e0a18ff34860e81a6d83aa5c (diff)
Import openssh_8.1p1.orig.tar.gz
Diffstat (limited to 'PROTOCOL.sshsig')
-rw-r--r--PROTOCOL.sshsig99
1 files changed, 99 insertions, 0 deletions
diff --git a/PROTOCOL.sshsig b/PROTOCOL.sshsig
new file mode 100644
index 000000000..720e1f18a
--- /dev/null
+++ b/PROTOCOL.sshsig
@@ -0,0 +1,99 @@
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 RFC4243 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