RFC 0066: Non-repudiable signature support about aries-rfcs

[swcurran]

@kdenhartog - another thing to make you sleep a little better at night. The issue of how/when to use different types of message encodings (is that the right term?) will occur more at the protocol definition/implementation level and less at the application layer - e.g. the code that controls/directs the agent. Since specs. are defined between collaborating parties, the spec. collaborators are more likely to get those things right (multiple eyeballs), and not expose the options to the app developers that will just use the protocol as spec'd/implemented. And, if there are protocol test suites, the implementations will match the spec.

Not perfect, but I think the selection of the message handling will not be left to the developer masses.

[dhh1128]

I vote jwe on the outside to follow OIDC.

[dhh1128]

@kdenhartog Thank you for patiently explaining. I think I get it now. Your comment that you wouldn't recommend this method now makes sense, and I agree with it. We need to be able to sign without exchanging secrets, or else we don't have a way to address the case where someone publicly signs for all the world to verify.

[andrewwhitehead]

@kdenhartog Looks good to me.

[kdenhartog]

Another relevant question. Would we rather a JWE(JWS(Content layer)) or JWS(JWE(Content layer))

My thinking is the JWE being on the outside would be preferred, but I'm curious if others could provide a case where the JWS on the outside makes more sense. From what I can tell Open ID connect wraps a JWE around the JWS.

[tplooker]

I second that too.

[tplooker]

JWE on the outside is currently how identity hubs are doing it, however they have a JWT on the inside, have we decided whether we will use a JWS or JWT?

[kdenhartog]

Cool thanks for clarifying. I've not gotten a chance to look at their structure of signatures. That's one of the next pieces I want to dig into. I know everyone is using JWTs, which from what I can tell just add optional fields like iss, sub, and others.

[kdenhartog]

Follow up to a question posed from @dhh1128 on rocketchat:

kdenhartog: JWTs support both repudiable signatures (like HMACs) and non-repudiable signatures (like digital signatures)...
dhh1128: ... Does it cease to become a signature in the sense that you know who affixed it? If so, what is preventing a middleman from replacing the content and affixing a different HMAC?

Turns out the HMAC uses a secret key (usually a symmetrical key also used for encryption) in order to prevent a middleman from replacing the content. Given the HMAC requires the combination of the signature and the key, the receiver would not be able to verify the message, and therefore the authenticity of the signature if the secret key wasn't used to produce the signature.

This means that a middleman would need the key to produced a forged signature or would need to discover an attack on the cryptography of the signature. More details about this can be found here. https://en.wikipedia.org/wiki/Digital_signature_forgery

However, given that HMAC based signature schemes require a symmetrical key, I wouldn't recommend this method as it increases the number of stored secrets needed for a connection (lightly opinionated on this). If we were to go this route, we would use the asymmetric keys listed in the DID Document and then derive a symmetrical key using ECDH or libsodium's scalarmult function and then keep this symmetrical key stored in the wallet for use later.

[kdenhartog]

Another question. I'd prefer to see this work handled by the pack/unpack API and plan to write an early demo showing it. The main advantage I'm after here is to contain all aspects of the cryptographic envelope in the pack/unpack API. I think this makes for a clean mapping to the mental model of how the envelope vs the content layer will work.

However, I'm concerned that adding this to the API will be a breaking change for one, and will add additional complexity to the API. As a quick poll, would others prefer that the signing of messages happens in a second API or would be combined with the current API?

[swcurran]

@kdenhartog - what would the API change be? Nice to see the current and revised if we stick with the extending the existing calls.

[tplooker]

My initial thoughts without knowing the structure of the new api would be to have it all handled via pack and unpack because as you identified @kdenhartog I think this further pushes the mental model of envelope vs content level.

[kdenhartog]

My initial thinking on it would be that I would add an additional boolean parameter signed (or some other more appropriate name) to the pack API with default set to false and when set to true it would add the JWS in. The unpack API wouldn't need any changing, but would output an additional value in the JSON similar to how unpack returns a key if it was authcrypted. I can propose a more concrete comparison in here when I start working on that section of the RFC.

One thing of note is that this RFC that I'm working on is only covering the entire message signing right now. I think it would be better to address the signature decorator separately so the two don't get conflated.

[dhh1128]

@kdenhartog Thank you for the explanation. However, if I read the explanation correctly, the signature depends on encryption being used as well. So this would not be an option if we were trying to sign plaintext. Is that accurate?

[kdenhartog]

@kdenhartog Thank you for the explanation. However, if I read the explanation correctly, the signature depends on encryption being used as well. So this would not be an option if we were trying to sign plaintext. Is that accurate?

It doesn't depend on encryption. A symmetrical key is most commonly used in encryption, but not exclusive to symmetrical encryption schemes. Essentially the "symmetrical key" would just be a random secret number that is shared by the parties signing and verifying, and cannot be revealed to others.

[TelegramSam]

Can we add an optional argument to include the signature, as well as signature methods when we are not encrypting?

[kdenhartog]

@TelegramSam That may be the best solution for this. I'll play around with this idea and see if I can get a demo going for that.

[kdenhartog]

On the Aries Call today @dhh1128 mentioned that we may not want say the use of the independent signature API should be limited to only DID Exchange protocol. While I think this may be overly restrictive, I'm looking to design the API in such a way that "If a developer makes a mistake, it's because they knew they were and did it intentionally".

Currently I'm working from the idea of 4 APIs.

pack_message(message, to_keys, from_keys = null, signed = false) => JWE(JWS(Content))

unpack_message(enc_message, to_keys) => 
{
       message: message,
       sender_key: sender_vk,
       recipient_key: recip_vk,
       verified: verified_bool
}

signContent(signing_key, message) => JWS

verifyContent = function(jws) => 
{
      content: decoded_content,
      verkey: verkey_used_to_sign,
      verified: verified_bool
}

Documentation would be a big help in preventing misuse, but I'm thinking how the APIs are designed could prevent mistakes as well. I'm not sure if what I'm suggesting even achieves the goal I'm looking for though. What's others thoughts on this? @andrewwhitehead @dhh1128 @tplooker @TelegramSam @troyronda @swcurran

[TelegramSam]

I have to preferences for this: 1. looks just like you describe above. 2. add an 'encrypted' arg to pack_message that defaults to true. Unpack would accept any form of any message, and indicate in the response what happened.

I'm not sure which of those two options I like yet.

[andrewwhitehead]

I see the signature decorator HIPE was closed in favour of this one, but at the moment they don't seem to provide the same functionality. When the signature decorator is used to sign the connection block of a connection response message, it is signed against the invitation key to prove that the sender created that invitation. The invitation key is not necessarily the same as the key they are using to encrypt the enclosing message (their pairwise verkey), especially in the case of a reusable invitation. In this case verification would fail as they are expected to match.

I think there might also be cases where the sender would want to include multiple signatures at the signing layer?

[TelegramSam]

As goals, we have:

• promote the ideal path: (encrypted, repudiable)
• Allow other paths when taken intentionally (non-repudiable, unencrypted)
• Make developer choices very clear.

To draw out my thinking, I have some modified signatures here:

pack_message(message, to_keys=null, from_keys = null, signed = false, encrypted = true) => JWE(Content) | JWS(Content)

unpack_message(enc_message, to_keys) => 
{
       message: message,
       sender_key: sender_vk, //if encrypted or signed
       recipient_key: recip_vk, //if encrypted
       encrypted: bool, //if message was encrypted
       signed: verified_bool //if message was signed
}

I think that pack_message(message, from_keys, signed=true, encrypted=false) is more obviously not encrypted then signContent(signing_key, message)

[TelegramSam]

@andrewwhitehead I do think we still need a way to sign part of a message. That is helpful for limiting the scope of non-repudiation.

[kdenhartog]

I agree there's a need for the partial signing of a message, but I intentionally put it out of scope at this point so I can think about the cryptographic layer only first and then think about the best way to integrate non-repudiation at the the content layer. I'll write up a sig decorator that's heavily dependent on this.

While I am trying to think about these parts individually I recognize we'll need to add this functionality to the content layer later. This is one of the secondary reasons I ended up separating the signContent() API. I makes it possible for easier sig decorator handling later. With the separate API a message handler would call the signContent() API inside the sig decorator handler.

As far as adding the encrypted API I think that could work. My two main squabbles with it are:

1.) The option of a choice forces a decision point on a developer to consider whether they should encrypt or not. I fear that by creating the option we're inadvertently encouraging finding reasons why messages shouldn't be encrypted and potentially encouraging conflation between the transport layer and the cryptographic layer. For example, someone may think that because the transport layer is encrypting that the use of encrypting messages is unjustified and then writes a protocol that requires transport layer security, but doesn't require encryption of messages. I think that by not including it we're forcing the developer to intentionally find a work around to make a message unencrypted.

2.) This is extremely nit picky. I think if we do this the API signature shouldn't place two booleans next to each other. This could lead to a mixup occurring where a developer intends to encrypt but not sign and instead flips it around.

The things I do like about this (as you've pointed out) is that the API requires explicit choosing to encrypt and sign for both. I think this hits the principle of "If a developer makes a mistake, it's because they did it intentionally".

Hmmm, I'm still undecided and could be easily convinced in either direction still. I'm going to continue watching how this discussion unfolds. The API is super easy to switch right now based on what I've coded up.

[dhh1128]

Maybe a solution could involve switching the way we talk about this, so that instead of encryption and signing, we talk about the appropriate goal instead? For example:

pack_sender_msg_for_recipients(msg, sender_key, recipient_keys, repudiable=true)
// always auth-crypts, sometimes signs

pack_anon_msg_for_recipients(msg, recipient_keys)
// always anon-crypts, never signs

pack_nonrepudiable_msg_for_anyone(msg, sender_key)
// never encrypts, always signs

[kdenhartog]

@dhh1128 I like the direction of this explicitness you're proposing. I'm also realizing the point you made when I first started working on this that too much magic causes more problems than it solves.

This allows for explicit documentation to help developers choose. I'm coming to accept that my biggest concern is that a developer doesn't understand the differences of non-repudiation vs repudiation, signing compared to encryption, and the methods of which they can be combined to create privacy. I feel the only way this can be fixed is with very clear documentation. I think these separate APIs will help to make it easier to documentation clearly as well.

[kdenhartog]

@swcurran I'm not sure it will help me sleep at night, but it may help me sleep in the early mornings 😄

On a more serious note, I do believe the point you bring up is a significant point. Assuming we end up with an openProtocol concept where protocols are at least documented openly this solves the problem. The one edge case (which has yet to happen yet) is a proprietarily developed protocol which wouldn't use these features properly. I think even in that case we can audit and reverse engineer proprietary protocols to verify they're using it properly. In this case, I'm less concerned about it and feel fairly convinced @dhh1128 method results in the best APIs for packing messages. On the unpack side I think it should remain a single API.

[andrewwhitehead]

@dhh1128 @kdenhartog While I like the approach of 'goal-oriented' method signatures, perhaps these could be implemented at the wrapper or framework level instead of being baked into the lowest layers, as that introduces more overhead (maintenance and testing) across the separate language wrappers. I'd prefer to have just one multi-purpose pack and unpack API at the rust level. pack may take a dictionary of parameters to allow for future extensions (which would be consistent with other API methods, like create_and_store_my_did for instance).

[kdenhartog]

I like the idea you've suggested. I'm going to plan on going that route @andrewwhitehead. I'll provide an example in the independent JS library of how this could work as well.

[kdenhartog]

I've got the JS library working based on the suggestions from @dhh1128 and @andrewwhitehead curious what peoples thoughts are for this. https://github.com/kdenhartog/DIDComm-js/blob/master/src/index.ts

[TelegramSam]

Discussed on the Aries WG Call 2019-12-11, and decided that it was complete.