On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura <[email protected]> wrote:
> On a side note: if such a spec is to be defined here, IMHO, it should use > the algorithms and probably header parameters specified by JWA, etc. It > should limit the scope to payload processing and expression of the entire > thing in JSON Log like format, and leave the rest to JOSE. > Absolutely. In fact that is why I am not raising it in JOSE as that just provides the format for the main crypto attributes. > On Thu Jan 29 2015 at 11:51:24 Manger, James < > [email protected]> wrote: > >> A signed JAR file meets some of these requirements. >> >> Metadata and signatures are in extra files in the ZIP archive: >> META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA. >> >> Content is the other files in the archive. >> >> It is not JSON of course, and the signature & certs are packaged in >> ASN.1, but it is a useful comparison. It avoids BASE64 on the content; can >> adds signatures, digests, and other metadata; can transport content and >> metadata as a regular blob (*.jar file); can sign complete code >> distributions. >> >> >> I have used signed jar files. But Sun rather poisoned the well there by suing Microsoft over control of Java followed up by further lawsuits from Oracle. I can't imagine anyone is going to accept Jar or anything involving assinine.1 as a wire format for packaging. Those days are long past. The way you get coherence is to pick one encoding and stick to it. JSON seems to have been the one we picked. It has all the functionality offered by the alternatives and none of the drawbacks.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
