Mohamed Boucadair has entered the following ballot position for draft-ietf-cose-merkle-tree-proofs-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Orie, Henk, Antoine, and Cédric, Thanks for the effort put into this specification. Please find some comments below: # CDDL is normative Please move to RFC8610 to be listed a normative. # Normative language Overall, the use of the normative language seems inconsistent, especially for the implementation behavior. Examples that triggered my comments are: It is recommended that implementations return a single boolean result for Receipt verification operations, to reduce the chance of accepting a valid signature over an invalid inclusion proof. Or It is recommended to select signature algorithms that share cryptographic components with the verifiable data structure used, And similar ones. Also, some clarity about object construction/verification behaviors vs. those related to actual use would be helpful. # Implementers or users? CURRENT: Implementers should not expect interoperability across "verifiable data structures", but they should expect conceptually similar properties across the different registered proof types. For example, 2 different merkle tree based verifiable data structures might both support proofs of inclusion. The first sentence in particular smells more relevant for actual use rather than design phase/implementers? Maybe I’m missing the point this text tries to make. Also, not sure what are the concrete implications of the interoperability mentioned here. # Why this isn’t a MUST? CURRENT (4.2): Security analysis SHOULD be conducted prior to migrating to new structures to ensure the new security and privacy assumptions are acceptable for the use case. # Check CURRENT (4.3): When the receipts header parameter is present, the associated verifiable data structure and verifiable data structure proofs MUST match entries present in the registries established in this specification. I guess you don’t imply the check should be against the initial values established by this doc, but also future registered values are covered. I suggest to make that more clear and consider this change: NEW: When the receipts header parameter is present, the associated verifiable data structure and verifiable data structure proofs MUST match entries present in the registries [IANA_URL]. BTW, which entity is required to do the analysis? Idem for which entity (user, implementer, verifier, etc.) is targeted by: A privacy analysis MUST be performed for all mandatory fields in profiles based on this specification. And A security analysis MUST be performed to ensure that the digital signature algorithm alg has the appropriate strength to secure receipts. # Each specification? CURRENT: Each specification MUST define how to encode the verifiable data ^^^^^^^^^^^^^^^^^^ structure identifier and its proof types in CBOR. Each specification ^^^^^^^^^^^^^^^^^^ MUST define how to produce and consume the supported proof types. See Section 5 as an example. Not sure to understand what is referred to by “Each specification” here. # Payloads Section 5.2.1 says: Specifications are encouraged to make payloads detached when possible, forcing ^^^^^^^^^^^^^^ validation-time comparison. and then The payload SHOULD be detached. What are the implications if this is not the case? # IANA Registries & Hidden Required IANA Actions CURRENT: IANA established the COSE Verifiable Data Structures and COSE Verifiable Data Structure Proofs registries under a Specification Required policy as described in [RFC8126]. I failed to find these. Can we please have pointers to where those are defined? Also, Section 4.1 says: This document establishes a registry of verifiable data structure algorithms, with the following initial contents: Idem, Section 4.2 states: This document establishes a registry of verifiable data structure algorithms, with the following initial contents: which seems a hidden IANA actions. Not sure, why these contents are not part of the IANA section, though. # Nits ## Title: Please expand COSE in the title. ## Abstract should be self-contained s/RFC 9162/“Certificate Transparency Version 2.0” (RFC 9162) ## Section 2 * s/ore more COSE Receipts/or more COSE Receipts * s/a new Section 8.2.2/ a new registry (Section 8.2.2) * s/a new Section 8.2.3/ a new registry (Section 8.2.3) ## Section 4.1 OLD: +================+=======+===========================+===========+ | Name | Value | Description | Reference | +================+=======+===========================+===========+ | Reserved | 0 | Reserved | Reserved | NEW: +================+=======+===========================+===========+ | Name | Value | Description | Reference | +================+=======+===========================+===========+ | Reserved | 0 | Reserved |THIS_DOCUMENT | ## Section 4.2 Please fix the following CURRENT: as EC2 keys (1: 2) keys ## Section 4.3 * s/This document registered/ This document registers * Which receipt/receipts are we referring to? CURRENT: to enable this Receipts to be conveyed in the protected and ^^^^ ^ ^ unprotected headers of COSE Objects. Also, check the singular/plural use. * OLD: The specific structure of COSE Receipts are dependent NEW: The specific structure of COSE Receipts is dependent ## Section 5.2 (1) CURRENT: Note that [RFC9162] defines that verification MUST fail if leaf-index is >= tree-size, and inclusion proofs are defined only for leaf nodes. May format this as a quote to insist this is not a NEW behavior. (2) s/verifiers applies/verifier applies Cheers, Med _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
