Roman Danyliw 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: ---------------------------------------------------------------------- Thank you to Linda Dunbar for the GENART review. ** Section 2. Editorial. Correspondingly, this document introduces a new Section 8.2.2 that registers the integers used to identify verifiable data structures. What does it mean to introduce a “new Section 8.2.2” per the write-up of TBD_1? Maybe: NEW Correspondingly, this document introduces a new registry (see Section 8.2.2) that registers the identifiers used to identify verifiable data structures. Same recommendation for TBD_2. ** Section 4.2. Table 2. Shouldn’t the values provided in the reference column also include an RFC in addition to the section numbers? ** Section 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 -- The situation where one is migrating between new structures isn’t sufficiently described -- When would security analysis NOT be appropriate (as a SHOULD is used)? Perhaps it might be better to use a lower case “should”. ** Section 5.1 5.1. Verifiable Data Structure The integer identifier for this Verifiable Data Structure is 1. The string identifier for this Verifiable Data Structure is "RFC9162_SHA256". See Table 1. See [RFC9162], 2.1.1. Definition of the Merkle Tree, for a complete description of this verifiable data structure. Should the text explicitly say (what is obvious from string identifier), that RFC9162_SHA256 is a Merkle Tree where SHA256 is used as the hash algorithm? ** Section 5.2. The term leaf-index is used for alignment with the use established in [RFC9162] Note that [RFC9162] defines that verification MUST fail if leaf-index is >= tree-size, and inclusion proofs are defined only for leaf nodes. The identifying index of a leaf node is relative to all nodes in the tree size for which the proof was obtained. Perhaps be clear that the term is “leaf_index” in Section 2.1.3.1 of RFC9162. ** Section 7 See the security considerations section of: * [RFC9162] * [RFC9053] -- Is this text saying that the security considerations of these two RFCs apply? -- The Security Considerations of RFC9162 seems to have significant guidance related to CT. Is there only a particular part of RFC9162’s Security Considerations which applies? ** Section 7.1 A security analysis MUST be performed to ensure that the digital signature algorithm alg has the appropriate strength to secure receipts. Is “MUST” the appropriate guidance here since an interoperable way to do “security analysis” on the appropriate strength isn’t clear? _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
