Hi, In my attempt to address the comments made on the provenance draft during the adoption call it is the turn for the first message Michael sent.
On 28/4/25, 15:19, <mcr+i...@sandelman.ca> wrote: I don't think you need canonicalization rules for CBOR, I think you should be citing RFC9254 (rather than RFC89439) which I think already has the rules. RFC 9254 is cited as one of the serialization methods in the signature structure, and it should be clear that the draft assumes RFC 9254 is applicable if CBOR is in use. But the RFC 8949 is cited as the mechanism to build a common, deterministic representation to be used for the signature and verification processes. We have used the term “Canonicalization” to refer to that process, as we understand it is common and well-understood. We are aware RFC 9254 use “deterministic encoding” and not “canonicalization”, and that the nature of the serialization implies particularities, but we believe including all of these methods under a common section (titled “canonicalization”) helps in structuring the discussion without compromising the technical soundness, as the references are used as normative without making any change on them. If you have a better title for the section, we would happily consider this for a next version. I find the way that the provenance leaf can appear anywhere (section 4.1) to questionable. Does YANG really allow this? The current wording in Section 4.1 could misleadingly suggest that a leaf can be added arbitrarily within any YANG structure. In fact, this must be done explicitly using augment, unless the original model already includes the required provenance-signature leaf. We have updated the text to clarify this point and reflect the correct use of augment for existing modules. It will appear in the next version, coming before the cut-off. I'm not sure I understand how the verifier knows what is being signed. I guess it's everything at that level, with the provenance leaf it self being empty. The procedures for building the signature and verifying it are detailed in each enclosing element definition. Let me remark the statements used for each one: For provenance signature as a leaf element (section 4.1): "The specific YANG content to be processed SHALL be generated by taking the whole enclosing element and eliminiating the leaf containing the provenance signature string.” For provenance signature in Notifications (section 4.2): "The signature is added to the notification envelope header [I-D.ietf-netconf-notif-envelope] as a new extension. The YANG content to be processed MUST consist of the content defined by the "contents" element [I-D.ietf-netconf-notif-envelope]" For provenance signature as metadata in a YANG Instance (section 4.3): " The specific YANG content to be processed SHALL be generated by taking the contents of the content-data element” For provenance in YANG Annotations (section 4.4): "The specific YANG content to be processed SHALL be generated by eliminating the provenance-string (encoded according to what is described in Section 5 of [RFC7952]) from the element it applies to”. If goes without saying we will happily update the descriptions with any suggestion you may have to may them clearer. I don't think OPSAWG is the right place for this work. I think it belongs in NETMOD, as this seems like YANG infrastructure, not a random model for some random protocol, which is more of an OPSAWG thing. It was introduced to NETMOD some time ago and sent back to OPSAWG. I do believe it belongs here, as we are talking about an operational enhancement for telemetry, configuration and other purposes. An IoTDIR/SECDIR review from a COSE expert is probably needed. Indeed. Anyway, one of the authors is at least familiar with COSE. And I agree we will need the review from the COSE community, in addition to the one from the YANG Doctors. Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica https://www.linkedin.com/in/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Mobile: +34 682 051 091 --------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
