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]
