|
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,
|
|
|
34 but only if there is a strong case for encouraging
|
|
|
35
|
|
|
36 [sender/receiver vs. client/server is confusing at best. Cf. ARCH
|
|
|
37 which tries to be clear wrt "sender gateway" and "recipient gateway",
|
|
|
38 but uses "client application" for both "originator" and "beneficiary"]
|
|
|
39
|
|
|
40 *Nits*
|
|
|
41
|
|
|
42 15.1
|
|
|
43
|
|
|
44 RFC 8446 is obsolete, should refer to 9846.
|
|
|
45
|
|
|
46
|
|
|
47
|