On Aug 4, 2011, at 07:38, Phillip Hallam-Baker wrote: > Since we are doing encryption as well, there are two problems needing a > common solution. > > > Let us say we are encrypting a blob of data - 200K or so. Do we really want > to have a JSON structure with the data blob JSON encoded? > > For that and for the signing case I think we are going to want a structure > that is something like: > > Package > [Type=JSON Length=203 bytes] > <Encryption stuff> > [ID=2as9uas9u9 Length=293939933 bytes] > <Binary blob> > > Ascii encoding for control data is good, it helps debugging etc. But Ascii > encoding JPEG bytes does not really help me much. > > The package could even be as simple as a JSON control block that gives the > length of a data blob that is to follow immediately. > >
We need to be *VERY* careful if the data ends up outside of the envelope. There are lots and lots of use cases where the data to be transferred is somewhat small (<1k), and there isn't a good mechanism for holding onto that outside data. We can't make the assumption that the only transport is HTTP! - m&m Matt Miller - <[email protected]> Collaboration Software Group - Cisco Systems, Inc. > On Thu, Aug 4, 2011 at 9:25 AM, John Bradley <[email protected]> wrote: > XPath is NOT the way to go. No argument from me. > > The JWS spec has admittedly been focused on allowing JSON to be used as > tokens for OAuth and openID. > > Those need to be passed around in a URL safe way, so we need a serialization > that supports that. > > In Quebec we did touch on alternate serializations that may be more suitable > for other use cases. > > I suspect that signing a manifest/reference is something we should be able to > support in the JOSE spec. > > Finding the best way to accommodate they without complicating the simpler > cases is something that should be explored. > > John B. > > On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote: > >> >> >> On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[email protected]> wrote: >> In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url >> encoded blobs. >> >> In most cased we intend for those to be JSON, but nothing prevents this from >> being used with XML similar to the failed SAML simple sign. >> >> With JSON payloads we really wanted to avoid touching the payload. >> Inserting elements, canonicalization and other things that touch the >> payload are highly problematic. >> >> I really want to avoid C18N as well. The problem is how to do it. >> >> If the data object is small it is no big deal base64 encoding it and storing >> it as an attribute. >> >> But if the data object is larger (XML document, image, etc.) then some form >> of indirection is going to be necessary. For example take the digest of the >> data and sign that or if multiple objects are involved some sort of manifest >> scheme. >> >> >> I really don't want to have to BASE64 a multimedia stream. So I think I am >> going to need some MIME like packaging scheme that allows us to send a JSON >> structure with attachments. I think that is going to be a very common >> requirement for others as well and I would like that to be a part of the >> standards toolkit rather than have to re-invent it for each protocol. >> >> >> Another very common corner case that is related is how to take a standard >> data object such as a JPEG, sign it and then attach the signature inside the >> data object. >> >> The blunder committed in XML Signature was to use XPath for that which >> introduced a mechanism for arbitrary transformations - yuk! >> >> I really don't want to specify the precise means of embedding signatures in >> various media types but I certainly need an approach that makes it possible >> to use the spec as a basis for doing that. >> >> >> -- >> Website: http://hallambaker.com/ >> > > > > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
