I now find myself hoping this is not the beginning someone making a case for ASN.1 encoding in WOES.
For my edification, can someone comment on how CMS would likely be referenced in WOES? Would it likely be a normative reference (i.e. key transport/wrapping, as it is in xmlenc-core), or otherwise would it probably be just informational? Paul On Mon, 2011-07-25 at 10:21 -0400, Richard L. Barnes wrote: > <hat type="individual"/> > > It's not clear to me what practical difference this requirement makes. I > would expect that the DER encoding of CMS is probably more compact than a > comparable JSON format, so you're not optimizing length by using JSON. And > JSON doesn't define a URL-safe encoding. If minimizing the size of something > in a URL is really your goal, it seems likely that size(base64(cms)) < > size(urlencode(json)). > > Or, if you're willing to take the JSON penalty in byte-efficiency, are you > trying to argue that there are fields that should be left out relative to > CMS? Could you point to some examples? > > --Richard > > > > On Jul 15, 2011, at 9:13 PM, Mike Jones wrote: > > > Some use cases require a compact, URL-safe data representation. For > > instance, this is needed when the data is passed in a URL query parameter - > > particularly for feature phone browsers that may limit URLs to 1024 or > > sometimes even 256 characters. That's one concrete example of something > > not covered by CMS. > > > > Some end-to-end use cases require a JSON key representation and ways of > > referring to them. That's another concrete example of something not > > covered in CMS. > > > > -- Mike > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Stephen Farrell > > Sent: Friday, July 15, 2011 5:36 PM > > To: Dave CROCKER > > Cc: [email protected] > > Subject: Re: [woes] New WOES charter proposal > > > > > > > > On 16/07/11 01:23, Dave CROCKER wrote: > >> > >> On 7/14/2011 1:45 PM, Stephen Farrell wrote: > >>>> The first requirement is for proponents to provide much more > >>>> explicit details about what is being proposed in the use of CMS. > >> ... > >>> Well, I don't really follow your logic there, but we're not aiming to > >>> do a new thing here. > >> ... > >>> Anyway the path for developing yet another crypto format is a pretty > >>> well trodden one and IMO CMS is the best current starting point for > >>> that process, so I think its entirely reasonable to ask people why > >>> they disagree with that. > >>> > >>> It does of course presume familiarity with CMS, but then that should > >>> be a prerequisite for working on woes, really. > >> > >> > >> Steve, > >> > >> Oh. This working group is merely a CMS encoding exercise? That was > >> not at all clear previously. > >> > >> I suspect I am not the only one who missed this as the anchoring and > >> inflexible premise to the work. (For reference, that requires even > >> stronger language than is in the current draft.) > > > > Maybe you could put [] around the sarcasm, given that this is JSON related? > > :-) > > > > I asked for examples of what's not covered by CMS but is needed here. I did > > that actually wanting to get an answer since I may well be missing > > something. (So far, no substantive answer has been offered.) I was not > > trying to score some rhetorical points. > > > > S. > > _______________________________________________ > > woes mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/woes > > > > _______________________________________________ > > woes mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/woes > > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
