|
19
|
1 https://datatracker.ietf.org/doc/draft-ietf-satp-core/
|
|
|
2 Document: https://www.ietf.org/archive/id/draft-ietf-satp-core-17.html
|
|
|
3 Title: Secure Asset Transfer Protocol (SATP) Core
|
|
|
4 Reviewer: Henry S. Thompson
|
|
|
5 Review Date: Mon Oct 19 13:48:49 2026
|
|
|
6
|
|
|
7 *Summary*
|
|
|
8
|
|
|
9 As far as I can tell as a non-specialist, the ... is in good shape.
|
|
|
10 There are ... below.
|
|
|
11
|
|
|
12 This draft is part of a package of at least three parts, including
|
|
|
13 also _Secure Asset Transfer (SAT) Interoperability Architecture_ and
|
|
|
14 _Secure Asset Transfer (SAT) Use Cases_.
|
|
|
15
|
|
|
16 *Minor points*
|
|
|
17
|
|
|
18 1.
|
|
|
19
|
|
|
20 The restriction to just HTTPS with TLS1.3 is almost certainly not
|
|
|
21 what you want. The use of HTTP/2 or QUIC, which requires use of
|
|
|
22 TLS1.3, should be allowed.
|
|
|
23
|
|
|
24 In the Introduction, all that's needed is something along these lines:
|
|
|
25
|
|
|
26 Secure transfer mechanisms such as HTTPS with TLS no less than 1.3
|
|
|
27 must be used.
|
|
|
28
|
|
|
29 5.3.9 and 5.4 can actually be simplified by switching to language
|
|
|
30 which allows for successor messaging systems which offer the same or
|
|
|
31 better security than HTTPS with TLS1.3.
|
|
|
32
|
|
|
33 There might be an argument for a SHOULD support HTTPS with TLS 1.3,
|
|
20
|
34 but only if there is a strong case for encouraging interop between
|
|
|
35 different gateway implementations.
|
|
|
36
|
|
|
37 5.3
|
|
|
38
|
|
|
39 The use of the word 'client' here and and client/server terminology
|
|
|
40 in 5.4 is unnecessarily confusing with respect to the use of
|
|
|
41 'client' as defined in section 3 and used in section 4 (the SATP
|
|
|
42 model) and 5.3.8.
|
|
|
43
|
|
|
44 The fact that 'client' is used with two different meanings in the
|
|
|
45 section headings of 5.3.8 and 5.3.10 illustrates this unnecessary
|
|
|
46 confusion.
|
|
|
47
|
|
|
48 ARCH uses 'client' only in the 'client application' sense, and
|
|
|
49 'server' not at all, and it would be a good idea to stick with that.
|
|
|
50 Following ARCH, Section 3 defines "sender gateway" and "recipient
|
|
|
51 gateway" and I would very much encourage their use throughout, as
|
|
|
52 already done in 5.3.2.
|
|
|
53
|
|
|
54 For example, 5.3 para 1 could read
|
|
|
55
|
|
|
56 SATP messages are exchanged between peer gateways, where depending
|
|
|
57 on the message type one is the sender gateway and the other the
|
|
|
58 recipient gateway.
|
|
|
59
|
|
|
60 and in 5.3.9
|
|
|
61
|
|
|
62 If the sender gateway transmits a list of supported credential
|
|
|
63 schemes, the recipient gateway selects one acceptable credential
|
|
|
64 scheme from the offered schemes.
|
|
|
65
|
|
|
66 and in 5.3.10
|
|
19
|
67
|
|
20
|
68 *5.3.10. Sender Gateway Offers Other Supported TLS Schemes*
|
|
|
69
|
|
|
70 If a sender gateway wishes to use TLS schemes other than the basic
|
|
|
71 scheme (AES-128 in GCM mode with SHA-256), then the gateway may
|
|
|
72 may choose to send a JSON object listing the client's supported
|
|
|
73 TLS schemes.
|
|
|
74
|
|
|
75 Also, later on the terminology used changes from 'recipient gateway'
|
|
|
76 to 'receiver gateway' -- this should be reverted throughout.
|
|
|
77
|
|
|
78 I've listed all this as 'minor' only because it is a matter of
|
|
|
79 terminology, but I think it's important to fix it.
|
|
|
80
|
|
|
81 5.4.1
|
|
|
82
|
|
|
83 See above. Here's a simpler version of this whole section:
|
|
|
84
|
|
|
85 5.4.1. Protocol requirements
|
|
|
86
|
|
|
87 Gateways MUST use a secure protocol, HTTPS or successors, in this stage.
|
|
|
88
|
|
|
89 Gateways MUST use the HTTPS POST method or equivalent idempotent
|
|
|
90 [RFC 9110] method in this stage.
|
|
|
91
|
|
|
92 7.
|
|
|
93
|
|
|
94 remove ' (client)' and ' (sender)'
|
|
|
95
|
|
|
96 8., 9., 10.
|
|
|
97
|
|
|
98 remove and/or replace 'client', 'server' and 'receiver' so that all
|
|
21
|
99 and only 'sender gateway' and 'recipient gateway' are used.
|
|
|
100
|
|
|
101 8.3. and others
|
|
|
102
|
|
|
103 Starting here there are many sentences of the form
|
|
20
|
104
|
|
21
|
105 "This message is sent from ... to the ... Endpoint at ... ."
|
|
|
106
|
|
|
107 The typography implies that these are formal properties of SATP, but
|
|
|
108 as far as I can see there is no definition of 'endpoint' or how the
|
|
|
109 many different ... Endpoints are to be identified between the two
|
|
|
110 gateways. Is this information meant to be included in the 'transfer
|
|
|
111 context' as defined in 5.3.6?
|
|
19
|
112
|
|
|
113 *Nits*
|
|
|
114
|
|
20
|
115 3.
|
|
|
116
|
|
|
117 Since you use them both, I suggest including the ARCH definitions of
|
|
|
118 'originator' and 'beneficiary' here.
|
|
|
119
|
|
|
120 5.3.15
|
|
|
121 'immobile' => 'immobilize' [twice]
|
|
|
122
|
|
|
123 'uses Hashed Time-lock' => 'use Hashed Time-lock'
|
|
|
124
|
|
21
|
125 8.1., 8.2., 8.6., 9.1, 10., 11.3., 11.4.
|
|
|
126
|
|
|
127 must => MUST [throughout]
|
|
|
128
|
|
|
129 8.4., 8.6. and 9 others
|
|
|
130
|
|
|
131 The example JSON ends with a comma, which is strictly speaking not
|
|
|
132 allowed, and may cause errors in some tools (e.g. jq). It would be
|
|
|
133 best to remove them.
|
|
|
134
|
|
|
135 11.3.
|
|
|
136
|
|
|
137 The example JSON is missing a comma after
|
|
|
138 "urn:ietf:params:satp:core:msgtype:transfer-proposal-msg"
|
|
|
139
|
|
|
140 12.
|
|
|
141
|
|
|
142 'such a' => 'such as'
|
|
|
143
|
|
19
|
144 15.1
|
|
|
145
|
|
|
146 RFC 8446 is obsolete, should refer to 9846.
|
|
|
147
|
|
|
148
|
|
|
149
|
