Hi Cullen, Generic answer to your message: please send text. More specifics below.
On 6/7/16 11:57 PM, Cullen Jennings wrote: > I like how this is evolving ... few things > > Few small things .... > > If you use CMS, I think you need to deal with how the JSON in canonicalized > before being signed. I will suggest that the standards the IETF created for > signing JSON would be a better choice for signing JSON than CMS - that's how > most other JSON based stuff does it. Within the bounds of widely available tooling I'm open to it, but would need to be convinced. I am somewhat comfortable with the CMS approach in which what we are signing is a file – the fact that it is JSON in incidental. What I would want see is a tool that can sign a JSON object and another one that can validate a signature through a chain of trust. In addition, there is a relationship between the signer of the MUD file and, if 802.1AR is in play, the signer of that certificate that should – somehow– be demonstrated. Ptrs welcome. > > Putting the last updated and cache validity in the file may not be a good > plan. More importantly putting it inside the stuff that is singed seems > problematic. "Cache Validity" may be a misnomer here. The intent is that because there may be millions of Things out there in tens of thousands of deployment, the manufacturers can hint at how long they do NOT wish to hear from a requester. View this as a minimum validity period, but by no means a maximum. Last-updated is just that, but I don't understand your concern. > > The "ietf-mud:direction" stuff seems a bit under specified. Does from-device > mean that if the device imitates the flow, responses to the flow also need to > flow to the device? It seems like the ietf-netmod-acl-model draft might be a > better place to specify this. Personally I would be happy for it to go into the ACL model, if that is netmod's wish. The only issue with that, and it is not a big issue, is that we chose terminology that was slightly mud-oriented so as to avoid confusion as to what "in" and "out" might mean. This can also be included as a separate augmentation in a separate module if people think that's appropriate but it is necessary for MUD, and so that's why it is where it is at the moment. Again, happy to go with other approaches so long as the WG is okay with them. > > Use of "ietf-mud" as prefix in the JSON for "ietf-mud:direction" is not how > JSON typically does this. You don't need a namespace because we know this is > a mud file thus know the namespace. A big reason some people moved from XML > to JSON was exactly to get rid of namespace. What's in there is what validates against pyang and yang2xml. No namespace is assumed on the outside, but rather the outer is ACL, and then on use where inner comes in, you need to name the namespace, or the tools will assume that MUD is invalid, as I understand it. Again, I am not a YANG expert. If the YANG people tell me I'm off base, I'd be happy to fix what's there. > > It's not a great practice to put ":" in the names of json attributes because > the way people use them in some languages often have them unquoted which you > can't do if there is a : in the name. You can do it, but "-" or "_" might be > better than ":" here. I'm concerned about tool breakage as well, then. However, this is how things are specified in draft-ietf-netmod-yang-json-10. We would need to revisit that there, and I'm happy with whatever outcome of that discussion would be. > > It would be great to have an simple example JSON file in the introduction > instead of (as well as a complete example in section 6) Good idea. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
