Ballot for draft-ietf-scitt-scrapi
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Needs 7 more YES or NO OBJECTION positions to pass.
Hi Henk, Jon, and Antoine, Thank you for the effort put into this specification. Thanks to Nick Buraglio for the OPSDIR review and the authors for addressing the review in -09. Please find below some points for DISCUSSion: # Lack of clear characterization of “Normative requirements” of SCITT CURRENT: This document defines a REST API that supports the normative requirements … ## It is not clear what are the normative requirements we are rereferring to. I failed to find in the document the mapping with specific parts in the architectures. ## Assuming we characterize those, is this spec covering all “requirements” or a subset? Are there requirements that are not normative? ## Some text is needed to help walk through the intended goal and the current specification. # NIST.SP.800-57pt1r5 CURRENT: Consistent with key management best practices described in [NIST.SP.800-57pt1r5] (Section 5.3.4), retired keys SHOULD remain available for as long as any Receipts signed with them ## Which part of that section are we referring to? I see some few normative uses in that section but not a 1:1 mapping with the language used here. ## That reference is what is present to back this reco and its citation strengthens the “best practice” claim, this is normative IMO. ## There are operational implications for storing such keys that should be called out. Likewise, there may be operational disruption if that SHOULD was not followed. Idem please consider flagging this in the spec. # MAY conflicts with MUST CURRENT: The following expected errors MUST be returned when the corresponding conditions are encountered. Implementations MAY return other errors, so long as they are valid [RFC9290] objects. Or The following expected errors MUST be returned when the corresponding conditions are encountered. Implementations MAY return other errors, so long as they are valid [RFC9290] objects. Unless I'm missing something subtle, these constructs are to be adjusted. # At least RFC9921 is normative CURRENT: [RFC9921] defines COSE header parameters for including [RFC3161] timestamp tokens that MAY be used for this purpose. Please note that per IESG Statement: Normative and Informative References, “Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references.” # Mix of IANA considerations and specification Section 5.1.1 (Resource Definition) provides normative behavior that is not adequate IMO in an IANA section, only the registration belongs there. Please consider moving that section to the main body.
# Please expand SCITT in the title. # Compliance with BCP56 Please check the use of normative language (and requiring some status codes) as I’m afraid some is not compliant with the guidance in Section 4.6 of RFC9205. # Operational Considerations CURRENT: In the absence of this header field, this document does not specify a minimum. CURRENT: If a client is polling for an in-progress registration too frequently then the Transparency Service MAY, in addition to implementing rate limiting This is left to implems. However, there are operational impacts if clients adopts an aggressive retry time. I suggest to discuss those, the need to configure server with a minimum, and a policy for rate-limit queries per client in a NEW Operational Considerations Section. # Conformance and Resources CURRENT: SCITT Reference APIs (SCRAPI) defines HTTP resources for a Transparency Service using COSE ([RFC9052]). The following resources MUST be implemented for conformance to this specification: * Registration of Signed Statements * Issuance and resolution of Receipts * Discovery of Transparency Service Keys ## Consider adding cross references to correlate each item with the section(s) that define those. ## Also, is that MUST same as what is in Section 2 CURRENT: The following HTTP resources MUST be implemented to enable conformance to this specification. If so, please keep MUST in one single place. # Need some motivation for some recommendations CURRENT: It is RECOMMENDED to use COSE Key Thumbprint, as defined in [RFC9679] as the mechanism to assign a kid to Transparency Service keys. Adding some justification/explanation of the recommendation would be helpful for those who will deploy to make their decision. # Inappropriate use of normative language, please fix OLD: Registration requests MAY fail, NEW: Registration requests may fail, Cheers, Med
This document does not spoecify a tranport mechanism, and I have transport review comments. Please find the following (non-blocking) COMMENTS: - There are two sentences that follow one another, and do not read correctly, please consider combining these: "Section 2 of [RFC7515] specifies Base64Url encoding as follows: [RFC7515] specifies Base64url encoding as follows:" Gorry