I had to go back and double check that I had things right but there is a trick that can be played for the PKCS#7 people.
A new content type id-ct-cborVoucher can be defined with the content of "these are the CBOR encoded bytes". That is NO ASN.1 wrapper is included. This works well for CMS The people who are stuck in the old world of PKCS #7 can encode this by using the ASN.1 type of OCTET STRING for this OID. The signature/verification process for them will strip the OCTET STRING type and lengths and just sign/verify the content of the OCTET STRING. This is the same as would be done for CMS. This trick works only if the new content type is OCTET STRING and would fail for any other ASN.1 type Jim > -----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 > > > Jim Schaad <[email protected]> wrote: > > * In section 1 para #4 you appear to have a formatting error where a list > > was supposed to exist. > > Thanks, I fixed that in the markdown. > > 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. > > 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. > > -- > ] 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
