DRAFT: digital signatures decorator and message family #79

kdenhartog · 2019-01-07T23:43:43Z

Signed-off-by: Kyle Den Hartog kdenhar@gmail.com

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

swcurran · 2019-01-09T15:52:54Z

text/digital-signatures/README.md

+The `@sig` feild decorator may be used with any field of data. Its value should match the json object format of the Signature Message Family outlined below. 
+
+```JSON
+"example_feild.@sig": {


Typo - feild

thanks, I'll get this changed on my next update.

swcurran · 2019-01-09T15:58:29Z

This is like the "attachments" HIPE in that it makes sense, but it would be great to have some use cases as to where this would be used.

I'm also intrigued as to using this with anoncrypt vs. using authcrypt. Could I get the same impact (same business function) of authcrypt by using anoncrypt and adding the signature decorator on the ciphertext field? I'm guessing not... :-)

tplooker · 2019-01-09T20:18:31Z

Great HIPE, once this has matured further I might modify #75 to use this functionality to provide proof of ownership of a routing identifier.

tplooker · 2019-01-09T20:19:58Z

text/digital-signatures/README.md

+
+```JSON
+{
+    @type: signature/1.0/ecdsa


Is there some sort of standardized signature qualification we could use here?

yeah, I believe the DID spec specifies them. This will need to be added before the propose phase.

kdenhartog · 2019-01-09T22:02:53Z

This is like the "attachments" HIPE in that it makes sense, but it would be great to have some use cases as to where this would be used.

I'm also intrigued as to using this with anoncrypt vs. using authcrypt. Could I get the same impact (same business function) of authcrypt by using anoncrypt and adding the signature decorator on the ciphertext field? I'm guessing not... :-)

I agree, I think a perfect first use case is with @tplooker PR #75 and we'll eventually need it for credentials as well.

With regards to the anoncrypt w/ signature decorator there is a slight difference. The difference being that with Authcrypt, repudiable authentication is used, where as with the suggestion you included it's non-repudiable authentication. These properties have subtle difference that will affect privacy which is why we've defaulted to using authcrypt with the option of adding non-repudiable signatures for authentication.

text/digital-signatures/README.md

TelegramSam · 2019-01-11T15:39:06Z

have some use cases as to where this would be used.

Connection protocol (and later maintenance) needs this.

TelegramSam · 2019-01-11T15:42:11Z

As I see it, these signatures can be processed by a receiving agent prior to presenting the data to a message handler. Then the handler can access the verified signature metadata and the signed data easily.

as an alternative, convenience functions can be used to access signed data inside the handler, to simplify the processing of these signatures.

Some quick text describing that intent could be helpful in the HIPE to help explain how the complexity of using these signatures can be mitigated.

mikelodder7

I don't know where you might build a list of acceptable signatures but we need to do it. At Real World Crypto 2019 Nadia Heninger presented a paper that uses lattice crypto to reverse engineer signatures to derive the private keys based on poorly generated nonces.

text/digital-signatures/README.md

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Updated handling, field renaming

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

mikelodder7 · 2019-01-29T03:04:12Z

text/digital-signatures/README.md

+How should multiple signatures be represented?
+    - One solution is to do [<digital_sig1>, <digital_sig2>] for `signature` and do [<verkey1>, <verkey2>] for `signers`


Cool idea but should be a separate HIPE.

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

TelegramSam · 2019-01-30T14:17:15Z

text/digital-signatures/README.md

+    @type: "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/signature/1.0/ed25519Sha512_single"
+    "signature": <digital signature function output>
+    "sig_data": <base64URL(64bit_integer_from_unix_epoch||message_data)>
+    "signers": <signing_verkey>


should this be signer insted of signers given that there will only be one for this signature type?

signers makes sense so its future proof. I vote for signers.

Are you seeing multi-sig format and single signer formats being the same @mikelodder7? That's what I was intending as well in which signers would make sense to use for this.

andrewwhitehead · 2019-02-09T20:47:23Z

I could use some detail on the timestamp representation, "append timestamp as 8 bytes to the front of the message data". Is that a big-endian unsigned (long) int?

swcurran · 2019-02-11T15:45:08Z

text/digital-signatures/README.md

+## Rationale and alternatives
+[alternatives]: #alternatives
+
+JSON Web Signatures is an alternative to this specification. The reason we've chosen to diverge from this specification is do to the inability to support our need for message decorators. Additional concerns around non-support for BLS signatures and other multi-signature schemes caused us to want to diverge.


Could you explain why JWS precludes message decorators? I don't get that from skimming the JWS spec.

The "non-support for BLS signatures" is a crypto thing beyond me, but it seems to me that the reasons need to be good for not to go with an existing spec.

I believe JWS formats won't work with CL Signature schemes, so if we intend to use this decorator with credentials, it wouldn't make sense to use it. However if we're looking to do just basic ed25519 signatures JWS would likely be the best format.

We could support BLS signatures for both threshold and multisigs, or even a single signer because those signatures are 1/2 the size of ECC sigs. CL sigs wouldn't work for JWS.

In the case of CL signatures and other considered Credential signatures would it make sense to use this format anyways? If it doesn't I see value in moving this format to align with the JWS work to allow for us to integrate with other identity systems more easily. (E.g. OAuth and openID connect servers)

mikelodder7 · 2019-02-19T03:53:55Z

I could use some detail on the timestamp representation, "append timestamp as 8 bytes to the front of the message data". Is that a big-endian unsigned (long) int?

That's what I thought it was. I agree it should be clarified to state "This timestamp field is a 64-bit unsigned big-endian integer. It records the number of seconds elapsed between January 1, 1970 UTC and the time the token was created."

kdenhartog · 2019-02-19T06:04:17Z

I could use some detail on the timestamp representation, "append timestamp as 8 bytes to the front of the message data". Is that a big-endian unsigned (long) int?

That's what I thought it was. I agree it should be clarified to state "This timestamp field is a 64-bit unsigned big-endian integer. It records the number of seconds elapsed between January 1, 1970 UTC and the time the token was created."

Thank you for clarifying. I hadn't gotten around to looking up what was being used in the standard. I'll add this detail to the HIPE.

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

kdenhartog · 2019-03-22T03:00:35Z

What's our consensus on moving this towards JWS? I'm in favor at this point.

dhh1128 · 2019-06-20T05:11:29Z

@kdenhartog Would you agree that this should now be moved over to aries-rfcs?

kdenhartog · 2019-06-20T05:15:20Z

I'd actually like to deprecate and close it (supersede in favor of 0066 is fine as well). This moves in a different direction than 0066 does, and I'm not wanting to separate out the decorator portion from the cryptographic envelope portion.

This is superseded by Aries RFC #66

initial draft of digital signatures

696bbae

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

swcurran reviewed Jan 9, 2019

View reviewed changes

tplooker reviewed Jan 9, 2019

View reviewed changes

TelegramSam reviewed Jan 11, 2019

View reviewed changes

text/digital-signatures/README.md Outdated Show resolved Hide resolved

TelegramSam reviewed Jan 11, 2019

View reviewed changes

text/digital-signatures/README.md Outdated Show resolved Hide resolved

mikelodder7 requested changes Jan 14, 2019

View reviewed changes

text/digital-signatures/README.md Show resolved Hide resolved

text/digital-signatures/README.md Show resolved Hide resolved

kdenhartog changed the title ~~initial draft of digital signatures~~ DRAFT: digital signatures decorator and message family Jan 16, 2019

TelegramSam and others added 4 commits January 21, 2019 10:35

Updated handling, field renaming

4f0bdbe

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Merge pull request #2 from TelegramSam/sigs

885f450

Updated handling, field renaming

updated HIPE with ~ and added details

ed33aad

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

update sigs HIPE

6d23d94

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

mikelodder7 reviewed Jan 29, 2019

View reviewed changes

add updates for connection protocol

72692a9

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

TelegramSam reviewed Jan 30, 2019

View reviewed changes

andrewwhitehead mentioned this pull request Feb 10, 2019

Add support for field signatures in agent messages bcgov/aries-vcr#74

Merged

swcurran reviewed Feb 11, 2019

View reviewed changes

updated timestamp details

d421fc7

Signed-off-by: Kyle Den Hartog <kdenhar@gmail.com>

kdenhartog closed this Jun 20, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DRAFT: digital signatures decorator and message family #79

DRAFT: digital signatures decorator and message family #79

kdenhartog commented Jan 7, 2019 •

edited

Loading

swcurran Jan 9, 2019

kdenhartog Jan 14, 2019

swcurran commented Jan 9, 2019

tplooker commented Jan 9, 2019

tplooker Jan 9, 2019

kdenhartog Jan 14, 2019

kdenhartog commented Jan 9, 2019

TelegramSam commented Jan 11, 2019

TelegramSam commented Jan 11, 2019

mikelodder7 left a comment

mikelodder7 Jan 29, 2019

TelegramSam Jan 30, 2019

mikelodder7 Feb 19, 2019

kdenhartog Feb 28, 2019

andrewwhitehead commented Feb 9, 2019

swcurran Feb 11, 2019

kdenhartog Feb 18, 2019

mikelodder7 Feb 19, 2019

kdenhartog Feb 28, 2019

mikelodder7 commented Feb 19, 2019

kdenhartog commented Feb 19, 2019

kdenhartog commented Mar 22, 2019

dhh1128 commented Jun 20, 2019

kdenhartog commented Jun 20, 2019

		How should multiple signatures be represented?
		- One solution is to do [<digital_sig1>, <digital_sig2>] for `signature` and do [<verkey1>, <verkey2>] for `signers`

DRAFT: digital signatures decorator and message family #79

DRAFT: digital signatures decorator and message family #79

Conversation

kdenhartog commented Jan 7, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swcurran commented Jan 9, 2019

tplooker commented Jan 9, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdenhartog commented Jan 9, 2019

TelegramSam commented Jan 11, 2019

TelegramSam commented Jan 11, 2019

mikelodder7 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewwhitehead commented Feb 9, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikelodder7 commented Feb 19, 2019

kdenhartog commented Feb 19, 2019

kdenhartog commented Mar 22, 2019

dhh1128 commented Jun 20, 2019

kdenhartog commented Jun 20, 2019

kdenhartog commented Jan 7, 2019 •

edited

Loading