|
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
|
|
|
99 and only 'sender gateway' and 'recipient gateway' are used
|
|
|
100
|
|
19
|
101
|
|
|
102 *Nits*
|
|
|
103
|
|
20
|
104 3.
|
|
|
105
|
|
|
106 Since you use them both, I suggest including the ARCH definitions of
|
|
|
107 'originator' and 'beneficiary' here.
|
|
|
108
|
|
|
109 5.3.15
|
|
|
110 'immobile' => 'immobilize' [twice]
|
|
|
111
|
|
|
112 'uses Hashed Time-lock' => 'use Hashed Time-lock'
|
|
|
113
|
|
19
|
114 15.1
|
|
|
115
|
|
|
116 RFC 8446 is obsolete, should refer to 9846.
|
|
|
117
|
|
|
118
|
|
|
119
|
