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]
