Hi Per, First of all, thanks for your support!
Let me try to address your comments: On 24/4/25, 14:22, <[email protected]> wrote: A comment I have raised in the past is why is the COSE_Sign1 signature [0] used? With this solution, only one signature can be attached. If instead the COSE_Sign signature structure [1] is used, multiple signatures can be attached. Examples where multiple signatures are useful are when more than one entity is required to sign off, using different signing algorithms, or migrating from an old key to a new key (havingboth signatures valid during the migration window). I strongly suggest the COSE_Sign signature structure is used instead of the COSE_Sign1 signature structure. The main reason to use the COSE_Sign1 signature was to keep the procedures for building and verifying as simple as possible. When we were considering one single enclosing method (the leaf element, described in section 4.1) I remember replying to a similar request that the need for multiple signatories could be addressed by the mechanisms proposed for recursive signature processing described in that section. Taking into account we have other enclosing methods at hand, applying COSE_Sign may become necessary. We need to analyze the implications this could have for signature building and validation, but we will be certainly considered. The draft currently uses draft-ahuang-notif-yang, this work has been replaced with draft-ietf-notif-envelope; which does not include an envelope for RFC 5277 NETCONF Notifications. This has been addressed by a pull request recently merged. It will appear in the upcoming version of the draft. Will the notification support defined in this document only be available for Subscribed Notifications? As far as I can tell, it should be available for any kind of notification. And I’d leave to those of you more familiar with the Notifications specs to point if there is anything that should be added or corrected to support this. It seems that the YANG module ietf-provenance-annotation is not used at all? If it should be used it needs work to conform to the IETF standards, which you are probably aware of. This is still among the TBDs in the draft (and marked as such in the current version). We have been focusing on validating the proposed approach and providing the famous running code. Now that we seem to have reached a more stable status, we plan to address this and other related issues. Actually, I was wondering whether the draft would be ripe for requesting an assessment from YANG Doctors… A nit is that maybe the signature-string leaf in the examples can either be wrapped or replaced with a placeholder value (e.g. BASE64VALUE=). Wrapped to make the strings readable. Together with a warning regarding this wrapping, this will be available in the new version to be uploaded before the cut-off date for Madrid. Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica https://www.linkedin.com/in/dr2lopez/ e-mail: [email protected]<mailto:[email protected]> Mobile: +34 682 051 091 --------------------------------- Thanks for your contribution! [0] https://datatracker.ietf.org/doc/html/rfc8152#section-4.2 [1] https://datatracker.ietf.org/doc/html/rfc8152#section-4.1 -- Per _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected] ________________________________ 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 -- [email protected] To unsubscribe send an email to [email protected]
