I saw that, I think I am going in a somewhat different direction, The detached payload option might be relevant.
I am moving to what is in effect a melange of QUIC tropes and JSON to create a drop in replacement for PKCS#7 and possibly moving to sequences of envelopes. On Mon, Mar 31, 2025 at 1:35 PM Michael Jones <[email protected]> wrote: > There’s also the JWS Unencoded Payload Option > https://www.rfc-editor.org/rfc/rfc7797. > > > > -- Mike > > > > *From:* Phillip Hallam-Baker <[email protected]> > *Sent:* Monday, March 31, 2025 8:56 AM > *To:* [email protected] > *Subject:* [jose] Large object signing and encryption with multiple > signatures > > > > All, > > > > I am working on a draft that is designed to make for secure use of QR > codes for JSContact data (among other things). Basic idea being Alice: > > > > * Puts her address/public key information for all her apps in her > JSContact. > > * JSContact is packaged up using QUIC varints for packaging and a JSON > header for metadata. > > * Result is encrypted using AES-GCM or the like and put on the server > > * The QR code contains the information necessary to locate, decrypt and > authenticate the data. > > > > And just because I can, I use the same 120-260 bit key for all three > purposes. > > > > Which is fine. But what about updates, what if Alice updates her contact > information. Do they have to wait till they meet in person again? We > obviously want to be able to include a key for verifying updates in the > first contact record and have a signature blob in the update. > > > > At which point I have (almost) re-invented JWS but with some important > differences. Most important of which being neither the payload nor the > ciphertext is BASE64 encoded. This is an efficient encoding and more like a > replacement for CMS than JWS. > > > > If the payload is 1240 bytes and the metadata is 80 bytes, the enveloped > data is going to be > > > > [length (1)][ header (80)][length (2)][ payload (1240)] > > > > So the total plaintext is 1323 bytes and the ciphertext is 1323+16 = 1339 > bytes. > > > > > > Right now, the code can only add a single signature but that is feeling a > bit limiting. Lets say Alice is working for a bank. She updates her work > contact details. Who should sign the update? Alice, the bank? How about > both? If both, it has to be possible to add a signature to an existing > envelope./ > > > > So I am considering re-using/revising the DARE Envelope scheme I developed > some time back. This has a related signature construction introducing a > manifest so that it is possible to add signatures to an existing item. > > > > > > My multisig package is constructed as follows: > > > > [Unprotected Header][Protected Header][Payload][Signatures] > > > > The Unprotected header has a series of pre-signature declarations > consisting of a key specifier (i.e. the key identifier or the key itself) > and a digest algorithm specifier. > > > > The signatures are then calculated over a manifest TBS. This obviously has > to include the protected header and the payload. I would also like to make > it possible to get a binding to the credential the document is signed > under. So the signatures are likely a JSON dictionary mapping key > identifiers to a {sig value, base64 (key)} tuple > > > > > > Was wondering if anyone else has done similar work I should be aware of, > in particular work that is currently applied. > > > > >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
