ietf-tapswg / api-drafts

Architecture, interface, and implementation drafts for the definition of an abstract API for IETF TAPS
Other
24 stars 15 forks source link

Roman Danyliw's DISCUSS #1462

Closed mwelzl closed 10 months ago

mwelzl commented 10 months ago

Thanks for the revised text in v-22, -23 and -24. I’m still do not understanding what exact Security Parameters that Section 6.3.1 is normatively specifying (and which of them are examples). My confusion is that Section 6.2 has a crisp list of parameters with an explicit names, type, and default value. The equivalent is not present for the security related parameters.

Section 6.3 says “except as noted below, as with the rest of the Transport Services API, exact names of parameters and/or values of enumerations (e.g., ciphersuites) used in the security parameters are system and implementation specific, and ought to be chosen to follow the principle of least surprise for users of the platform / language environment in question.” How does one read “except when noted below”? Is this section saying the normative parameters are server-certificate, client-certificate, pinned-server-certificate, alpn, supported-group, ciphersuite, signature-algorithm, max-cached-sessions, cached-session-lifetime-seconds, pre-shared-key OR that “an API should define certificate bundles, certificate chains for pinned certificates, ALPN, session cache management parameters, supported groups/ciphersuite/ parameters, and PSK parameters but no further details are provided here beyond naming these categories of parameters”?

I observe that the guidance in Section 4.1 suggests that parameter names are in CamelCase. That isn’t used here (e.g., “server-certificate” should be “ServerCertificate”). This might hint that there are not parameters here. However, the bulleted list in Section 6.3.1. is prefaced with “Security configuration parameters and sample usage follow:” seems to suggest that these are concrete parameters.