Hi Jan, First of all, my apologies (to you and the whole OPSAWG crowd) for the belated reply. I returned home to find a pile of unpostponable assignments from my management that, combined with the Christmas break and the injury I suffered during it, have caused an enormous backlog in my email and related tasks. Now it seems I have found some time to try to get up to date with my pending IETF obligations…
Thanks for your comments. Let me try to address them and include some hints on the new version of the draft we are working on currently. First of all, I would have expected this sort of "meta" information to be mapped to attributes in XML or JSON (as described by existing RFCs). For CBOR I have to admit I don't know what is said about attributes. But I guess mapping this to (config false) leafs that are tactically augmented in by server implementors should work too, and may even have some benefits. There have been some comments in the direction of using elements outside the data modeles themselves, such as YANG Push envelope or checksums associated with files. Actually, we are considering the possibility of specifying a general method to generate and verify COSE signatures of YANG data, and propose several “embodiments”, if you allow me the patent-like parlance, for coming version. These “embodiments” would be applied depending on whether it is decided to include the provenance signature as part of the YANG module, as part of the envelope (exemplified by YANG Push), as part of some metadata, and/or some kind of checksum value (focused on data at rest). I would favor the first option, since it would imply a specific interest of the designers to support provenance checking, make this checks indpendent of how the data has been processed/stored, and therefore allow for specific checkings at any stage of the data lifecycle, but after the discussions in Prague and later on the list, it is true the other options would maximize the usefulness of this approach. Rather than specifying a typedef, I would suggest that you create a grouping (with a single leaf). This has the added benefit that you can ensure the name of the leaf is the same every time (which reinforces the idea that only one such leaf is possible on every level in the tree) and that nobody will miss modeling this leaf as config false, even if it appeared in a config true context. This sounds like a quite sensible idea. We will update the coming version accordingly. You have some examples that place the platform-provenance leaf first in lists. I would strongly recommend against this, even in examples, since (in XML) the list keys MUST go first in the instance data. A rather common server implementor beginner's mistake is to forget this, and I don't think we'd want to muddle the waters more with examples of this kind. I'd suggest placing the platform-provenance leaf after the list key(s), or maybe last. When writing the examples we put the provenance leaf first with the idea of simplify the trees, but your right this may cause misinterpretations, especialluy serious if we consider the requirement you mention. This will be corrected in the next version. How would a validating client know which leafs are provenance-signatures? Should it go by leaf name (trying to validate any container/list that has a leaf called "provenance-signature" in any namespace? Should it examine the leaf type? Marking by YANG extension...? Our original idea was that the client should identify them from the module definition, as the provenance signatures would be defined by their type. With the pattern you propose, it could do it as well by identifying the groupings with a (single) leaf with the predefined name. The point here is that provenance validation is not mandatory for the clients: they have the possibility to decide whether to run a verification or not, depending on the case. And, what I believe it is more important, thet can apply this verification at the level they decide. As discussed in the draft, provenance signature can be nested, and the client could decide to run the verification for the most appropriate data source or sources. We’ll include a discussion on this for the next version. For sure, if we go for the alternate “embodiments”, the rules for identifying the provenance signature should have to be specified accordingly. In section 4, the need for canonicalization is mentioned, and algorithm described. The algo for XML is really only about reordering and sometimes moving or excluding XML attributes. I'm not saying canonicalization isn't needed, but I don't see exactly what purpose you have in mind for doing this is. If all we are after is to verify that a particular string (XML, JSON or whatever) has not been tampered with, I guess canonicalization would not really be needed? If it indeed is needed, is the light algorithm referenced enough to achieve your intended purpose? I mean, the payload is not canonicalized when it comes to whitespace, ordering of elements and many other aspects. Will your purpose still be fulfilled? Canonicalization is an essential mechanism for digital signatures of documents, based on real-life experience. Please bear in mind that we are not talking about canonicalizing the representation that goes on the wire or is stored, but to do so with the document before the signature is generated or verified, so we can be sure the signature mechanisms are being to a unique, canonical, representation of the document. We are now experimenting with a practical implementation and, as far as I can tell, the proposed canonicalization methods work. But always happy to hear any advice or experience realted to them. Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/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] https://www.ietf.org/mailman/listinfo/opsawg
