1
1
# $signing_spec
2
2
3
- A signature scheme for software supply chain metadata that avoids canonicalization
3
+ A signature scheme for software supply chain metadata that avoids
4
+ canonicalization
4
5
5
6
November 25, 2020
6
7
@@ -33,7 +34,7 @@ The signature format is a JSON message of the following form:
33
34
"payloadType" : " <PAYLOAD_TYPE>" ,
34
35
"signatures" : [{
35
36
"keyid" : " <KEYID>" ,
36
- "sig" : " <Base64(Sign(PAE([ UTF8(PAYLOAD_TYPE), SERIALIZED_BODY] )))>"
37
+ "sig" : " <Base64(Sign(PAE(UTF8(PAYLOAD_TYPE), SERIALIZED_BODY)))>"
37
38
}]
38
39
}
39
40
```
@@ -70,7 +71,7 @@ Functions:
70
71
where parameters ` type ` and ` body ` are byte sequences:
71
72
72
73
``` none
73
- PAE([ type, body] ) := le64(2) || le64(len(type)) || type || le64(len(body)) || body
74
+ PAE(type, body) := le64(2) || le64(len(type)) || type || le64(len(body)) || body
74
75
le64(n) := 64-bit little-endian encoding of `n`, where 0 <= n < 2^63
75
76
```
76
77
@@ -87,11 +88,17 @@ Functions:
87
88
88
89
### Steps
89
90
91
+ Out of band:
92
+
93
+ - Agree on a PAYLOAD_TYPE and cryptographic details.
94
+ - Decide if [backwards compatible signature] mode should be allowed.
95
+
90
96
To sign:
91
97
92
- - Serialize BODY according to PAYLOAD_TYPE. Call the result SERIALIZED_BODY.
93
- - Sign PAE([UTF8(PAYLOAD_TYPE), SERIALIZED_BODY]), base64-encode the result,
94
- and store it in `sig`.
98
+ - Serialize the message according to PAYLOAD_TYPE. Call the result
99
+ SERIALIZED_BODY.
100
+ - Sign PAE(UTF8(PAYLOAD_TYPE), SERIALIZED_BODY), base64-encode the result, and
101
+ store it in `sig`.
95
102
- Optionally, compute a KEYID and store it in `keyid`.
96
103
- Base64-encode SERIALIZED_BODY and store it in `payload`.
97
104
- Store PAYLOAD_TYPE in `payloadType`.
@@ -100,8 +107,9 @@ To verify:
100
107
101
108
- Base64-decode `payload`; call this SERIALIZED_BODY. Reject if the decoding
102
109
fails.
103
- - Base64-decode `sig` and verify PAE([ UTF8(PAYLOAD_TYPE), SERIALIZED_BODY] ).
110
+ - Base64-decode `sig` and verify PAE(UTF8(PAYLOAD_TYPE), SERIALIZED_BODY).
104
111
Reject if either the decoding or the signature verification fails.
112
+ - Reject if PAYLOAD_TYPE is not a supported type.
105
113
- Parse SERIALIZED_BODY according to PAYLOAD_TYPE. Reject if the parsing
106
114
fails.
107
115
@@ -297,14 +305,14 @@ Rationales for specific decisions:
297
305
2 . It would incur double base64 encoding overhead for non-JSON payloads.
298
306
3 . It is more complex than PAE.
299
307
300
- ## Backwards Compatibility
308
+ ## Backwards compatibility with existing TUF and in-toto signatures
301
309
302
310
### Current format
303
311
304
312
The
305
- [ current signature format] ( https://github.com/in-toto/docs/blob/master/in-toto-spec.md#42-file-formats-general-principles )
306
- used by TUF and in-toto has a BODY that is a regular JSON object and a signature over the
307
- [ Canonical JSON] serialization of BODY.
313
+ [ old signature format] ( https://github.com/in-toto/docs/blob/master/in-toto-spec.md#42-file-formats-general-principles )
314
+ used by TUF and in-toto has a BODY that is a regular JSON object and a signature
315
+ over the [ Canonical JSON] serialization of BODY.
308
316
309
317
``` json
310
318
{
@@ -344,7 +352,7 @@ To convert a backwards compatible signature to the old format:
344
352
See [ reference implementation] ( reference_implementation.ipynb ) . Here is an
345
353
example.
346
354
347
- BODY :
355
+ SERIALIZED_BODY :
348
356
349
357
``` none
350
358
hello world
@@ -385,10 +393,11 @@ Signed wrapper:
385
393
386
394
## References
387
395
388
- - [ Canonical JSON]
389
- - [ JWS]
390
- - [ PASETO]
396
+ - [ Canonical JSON]
397
+ - [ JWS]
398
+ - [ PASETO]
391
399
400
+ [ backwards compatible signature ] : #backwards-compatible-signatures
392
401
[ Canonical JSON ] : http://wiki.laptop.org/go/Canonical_JSON
393
402
[ JWS ] : https://tools.ietf.org/html/rfc7515
394
403
[ PASETO ] : https://github.com/paragonie/paseto/blob/master/docs/01-Protocol-Versions/Version2.md#sig
0 commit comments