Mercurial > hg > ietf

comparison satp-core-review.txt @ 19:7f1bd15f2d23

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
getting started
author Henry S. Thompson <ht@inf.ed.ac.uk>
date Tue, 20 Oct 2026 19:49:34 +0100
parents
children 7cf0c76e9749
comparison
equal deleted inserted replaced
18:d8dde47d0a7f 19:7f1bd15f2d23
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