diff options
author | Colin Watson <cjwatson@debian.org> | 2019-10-09 22:59:48 +0100 |
---|---|---|
committer | Colin Watson <cjwatson@debian.org> | 2019-10-09 22:59:48 +0100 |
commit | 4213eec74e74de6310c27a40c3e9759a08a73996 (patch) | |
tree | e97a6dcafc6763aea7c804e4e113c2750cb1400d /PROTOCOL.sshsig | |
parent | 102062f825fb26a74295a1c089c00c4c4c76b68a (diff) | |
parent | cdf1d0a9f5d18535e0a18ff34860e81a6d83aa5c (diff) |
Import openssh_8.1p1.orig.tar.gz
Diffstat (limited to 'PROTOCOL.sshsig')
-rw-r--r-- | PROTOCOL.sshsig | 99 |
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 @@ | |||
1 | This document describes a lightweight SSH Signature format | ||
2 | that is compatible with SSH keys and wire formats. | ||
3 | |||
4 | At present, only detached and armored signatures are supported. | ||
5 | |||
6 | 1. Armored format | ||
7 | |||
8 | The Armored SSH signatures consist of a header, a base64 | ||
9 | encoded blob, and a footer. | ||
10 | |||
11 | The header is the string "-----BEGIN SSH SIGNATURE-----" | ||
12 | followed by a newline. The footer is the string | ||
13 | "-----END SSH SIGNATURE-----" immediately after a newline. | ||
14 | |||
15 | The header MUST be present at the start of every signature. | ||
16 | Files containing the signature MUST start with the header. | ||
17 | Likewise, the footer MUST be present at the end of every | ||
18 | signature. | ||
19 | |||
20 | The base64 encoded blob SHOULD be broken up by newlines | ||
21 | every 76 characters. | ||
22 | |||
23 | Example: | ||
24 | |||
25 | -----BEGIN SSH SIGNATURE----- | ||
26 | U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgJKxoLBJBivUPNTUJUSslQTt2hD | ||
27 | jozKvHarKeN8uYFqgAAAADZm9vAAAAAAAAAFMAAAALc3NoLWVkMjU1MTkAAABAKNC4IEbt | ||
28 | Tq0Fb56xhtuE1/lK9H9RZJfON4o6hE9R4ZGFX98gy0+fFJ/1d2/RxnZky0Y7GojwrZkrHT | ||
29 | FgCqVWAQ== | ||
30 | -----END SSH SIGNATURE----- | ||
31 | |||
32 | 2. 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 | |||
45 | The publickey field MUST contain the serialisation of the | ||
46 | public key used to make the signature using the usual SSH | ||
47 | encoding rules, i.e RFC4253, RFC5656, | ||
48 | draft-ietf-curdle-ssh-ed25519-ed448, etc. | ||
49 | |||
50 | Verifiers MUST reject signatures with versions greater than those | ||
51 | they support. | ||
52 | |||
53 | The purpose of the namespace value is to specify a unambiguous | ||
54 | interpretation domain for the signature, e.g. file signing. | ||
55 | This prevents cross-protocol attacks caused by signatures | ||
56 | intended for one intended domain being accepted in another. | ||
57 | The namespace value MUST NOT be the empty string. | ||
58 | |||
59 | The reserved value is present to encode future information | ||
60 | (e.g. tags) into the signature. Implementations should ignore | ||
61 | the reserved field if it is not empty. | ||
62 | |||
63 | Data to be signed is first hashed with the specified hash_algorithm. | ||
64 | This is done to limit the amount of data presented to the signature | ||
65 | operation, which may be of concern if the signing key is held in limited | ||
66 | or slow hardware or on a remote ssh-agent. The supported hash algorithms | ||
67 | are "sha256" and "sha512". | ||
68 | |||
69 | The signature itself is made using the SSH signature algorithm and | ||
70 | encoding rules for the chosen key type. For RSA signatures, the | ||
71 | signature algorithm must be "rsa-sha2-512" or "rsa-sha2-256" (i.e. | ||
72 | not the legacy RSA-SHA1 "ssh-rsa"). | ||
73 | |||
74 | This blob is encoded as a string using the RFC4243 encoding | ||
75 | rules and base64 encoded to form the middle part of the | ||
76 | armored signature. | ||
77 | |||
78 | |||
79 | 3. 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 | |||
89 | The preamble is the six-byte sequence "SSHSIG". It is included to | ||
90 | ensure that manual signatures can never be confused with any message | ||
91 | signed during SSH user or host authentication. | ||
92 | |||
93 | The reserved value is present to encode future information | ||
94 | (e.g. tags) into the signature. Implementations should ignore | ||
95 | the reserved field if it is not empty. | ||
96 | |||
97 | The data is concatenated and passed to the SSH signing | ||
98 | function. | ||
99 | |||