RFC 0029: signature verification and MTC about aries-rfcs

[dhh1128]

You're right. I wasn't being careful enough in my analysis. Having a message where 2 subsets of the content are signed, and both signatures verify, is definitely different from having a message where the entire message is signed and it verifies. We can't use NONREPUDIABLE for both.

I'm still thinking about the rest of what you said.

[dhh1128]

Really, really good questions.

The intent was that the NONREPUDIABLE attribute of an MTC would equate to what you are calling SIG_VERIFY_OK.

I agree that having a signature over a specific subset of a message's content, and having a signature over the entire message, muddies the water. But I wonder if incomplete signature verification is really useful; could we just say that either all signatures validate, or else the whole message is unworthy of the NONREPUDIABLE flag?

I'm feeling like we should shy away from extra complexity if we can get away with it, because right now code written by @dbluhm and code written by me are the only two impls I know of for MTCs, and I want to make it easy to pick up support; I think pretty good MTCs that are widely adopted would be better than highly precise, granular/recursive MTCs that feel too intimidating to back into impls.

That's just a quick gut reaction, though. I could be talked out of it.

[dbluhm]

I understand the reasoning to keep MTCs simple and I think I agree.

I agree that having a signature over a specific subset of a message's content, and having a signature over the entire message, muddies the water. But I wonder if incomplete signature verification is really useful; could we just say that either all signatures validate, or else the whole message is unworthy of the NONREPUDIABLE flag?

I'm not sure I follow here. If we did have a message with one or multiple signed subsets of content and the signatures verify, applying NONREPUDIABLE to the whole message would seem to imply that any contents outside of those subsets are also nonrepudiable which would not be true.

I wonder if a solution to the muddiness would be to let NONREPUDIABLE apply to whole messages and perhaps have custom trust attributes for specific fields of a message that have been signed. Going back to my original example from the connection protocol, as a signature verifying pre-processor successfully verifies the connection~sig decorated field, it could add CONNECTION_SIG_VERIFIED. This may still be falling into "highly precise" land and I'm still not quite certain the benefits outweigh the added complexity.

[kdenhartog]

This is an interesting angle that reinforces my thinking that the ~sig decorator may be more complex than we originally thought. I agree with the analysis that @dbluhm has provided around needing to provide attribute specific MTCs for the ~sig decorator. I wonder if this is limited to this decorator only (because it's cryptographic in nature) or if this is more common to all decorators.

[dbluhm]

With the move to use ~attach with a signature instead of ~sig, I think a solution becomes clearer; attached documents can be more cleanly thought of as separate messages with their own associated trust context, with some of its attributes being inherited from the parent message.

[TelegramSam]

@dbluhm agreed to do some RFC Updates to capture tribal knowledge. Will close after that has happened.

[dbluhm]

PR #346 in with a small update to the MTC RFC that attempts to capture the outcome of this discussion. I'll go ahead and close this issue.