> -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Monday, April 30, 2018 12:18 PM > To: [email protected]; Jim Schaad <[email protected]> > Cc: [email protected] > Subject: Re: draft-richardson-anima-ace-constrained-voucher > > > peter van der Stok <[email protected]> wrote: > >> * Section 5 - you have a return of multiple items with the same rt value. > >> However I would not want to have to filter through the list of return > >> values > >> to figure out which is the "root" one. Should this example have the > >> rt=ace.est attribute on all of the links? > > > The example is an example and people can decide to do it differently. > > Two alternatives: > > - only return the root collection > > - define additional rt values per resource > > > > You have a preference? I prefer the first approach > > I'm not clueful about this part, and generally quite fearful about parsing this > stuff. Sure, it's easy in Ruby, but it's the constrained C code that I'm > concerned about, so I don't understand the tradeoffs here.
There are a couple of questions that I would put here that I think guides things. * Is there any expectation that the path components would ever change for some implementation or are they always going to be the same? Would a request voucher always be posted to /rv or could an implementation change it to be /rvr? * Is there a reason for an endpoint to want to get what services are supported as a general rule rather than just assuming that if the root exists then all of the services are also going to exist. If the answer to the first question is no, then I don't know that they even need to have resource types. You get the root and go from there. If the answer to both questions is yes, then a different rt for every service would be needed so that they can be distinguished. If the answer to the first question is no and the second is yes, then it would make sense to define a generic rt='ace.est.service' so that the root and the list of services can be queried for individually. > > jim> * Suggest a strong recommendation on not use cmsVersion=1 to > make your life > jim> easier. > > In other words: to not be PKCS7 compatible, but require CMS processing. > > I think this is reasonable from a specification point of view, but there has > been pushback from people who have FIPS-140 libraries that they have hard > times getting updated. Just to be clear, they have updated the library sufficiently to be able to verify CMS messages but not to create them? We are also talking about libraries which have not been updated to deal with any 'new' crypto as that would not be supported by old bcrypt libraries as well. Note this is also an interesting question for how you are going to label the CBOR encoded voucher. If you use id-data, then the question is moot and everybody goes forward happy. On the other hand if you assign a new OID for this then it would need to be an ASN.1 object for the PKCKS7 people to encode based on my historic work with such packages. This is because for types which are not id-data the type and length bytes are stripped from the content before it is processed by the PKCS#7 library. Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails [ > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
