Hi Rob, The long time our response has taken was not only caused by the usual overload and the Christmas break but also because we have been making an analysis of the possible further enhancements you hint.
First of all, let me insist on one key aspect: the approach described in this draft addresses the provenance of concrete YANG instances, in its XML, JSON and (now) CBOR formats, so the signature and verification procedures are intended to be applied to the concrete instance, with the precise serialization used for it, and therefore it is required to apply the common practices for the signature of such an instance. Now, let’s go through the concrete points you made. On 3/11/25, 23:31, <[email protected]> wrote: 1. You have chosen to do the normalisation over the instance data but still represented as a JSON or XML document. I was wondering whether there should be an abstract normalisation of YANG instance data and an algorithm to generate a COSE signature based on that abstract structure rather than tying it to the encoding. This would imply some kind of “semantic normalization”, and would require an ontology representation of the YANG model able to support that process. We are aware of some work in this area, focused on RDF representations, and this could be an interesting way to explore in a (series of) possible future draft(s), but we believe this goes well beyond the goal of the provenance mechanisms we are considering here. 1. An alternative could be to sign the data as an opaque stream of bytes, without any normalisation first. Although I guess the means that you lose the provenance if you restructure the data into a different form. That would be the case indeed. The focus of normalization is precisely to consistently provide a verifiable signature. Anyway, this discussion gave us the idea to consider some stream signing algorithms, which would be ideally more efficient than the full in-memory mechanisms we are using right now. Anyway, that would become an implementation improvement, but the process would stay the same. 1. Similar to what Thomas mentioned, for a JSON encoding you are technically allowed to return the elements in a list/container in any order. Your normalisation would naturally put tighter constraints on how that data is structured, this may be okay, but is worth being aware of, and probably explicitly pulling those out. What I was trying to tell Thomas is that normalization is used precisely for taking this into account, making it possible to get a consistent and verifiable signature independently of these variations. This comment made me think we did not make the normalization process clear enough. The process is applied to the data just before generating the signature value (either for signing or verification), but it does not imply any change to the original data, nor is a constraint on the original data format. I think an example would help with this. Let’s assume we have a vector with three values: A, B and C. The encoding we use makes totally equivalent those values in any order: (A, B, C), (B, A, C), (C, B, A), or any other permutation mean exactly the same. What normalization would do in this case is to take these values and put them in a specific order for generating the signature, so when you apply the signature function (let’s call H()) it provides the same value. If we assume the normalization consists in applying alphabetical order, what we would have after signing would be, for the three examples above: (A, B, C) + H(A, B, C) (B, A, C) + H(A, B, C) (C, B, A) + H(A, B, C) So equivalent vectors would generate the same signature, but their content is not altered by any means. I hope this makes things clearer. 1. In the Yang Push header your provenance leaf is before the data, but I think that it should probably be after the data (or as Thomas said, it should be flexible as to where it contained). That potentially allows implementations to write a signature after the data has been processed rather than caching the structure in memory first. That’s a valid point. The position of the signature has been a matter of several discussions, caused by different views on what I would call “structuring styles”. But this argument you use has a much heavier weight that those styles and we have changed the draft and the reference implementation we will demonstrate (in its final version) at the Hackathon. 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 --------------------------------- ________________________________ 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]
