reconsider threshold (aka multi-sig) verification

[jku]

While reviewing the (python) securesystemslib implementation I was a little unhappy with the multi-sig verification:

• it feels like it maybe should not be part of an envelope protocol: DSSE looks like clean way to deliver payloads and signatures -- what a signature, or the number of signatures, means is really up to a higher level layer. I can easily imagine other mechanisms than the algorithm in the spec (easy example: always require sig from a specific build system key and N-of-M developer keys)
• the multi-sig verification algorithm also can't really be fully implemented by a generic DSSE implementation (because it requires checking the payload type and deserializing the payload which a generic implementation cannot do)
• the algorithm requires the implementation to break when threshold is reached: this means logging, auditing and possibly returning all valid signatures would have to be implemented somewhere else

Thoughts?

[jku]

the algorithm requires the implementation to break when threshold is reached

go-securesystemslib does not seem to implement this either

[lukpueh]

While reviewing the (python) securesystemslib implementation I was a little unhappy with the multi-sig verification:

• it feels like it maybe should not be part of an envelope protocol: DSSE looks like clean way to deliver payloads and signatures -- what a signature, or the number of signatures, means is really up to a higher level layer. I can easily imagine other mechanisms than the algorithm in the spec (easy example: always require sig from a specific build system key and N-of-M developer keys)

IIUC you are saying that signature verification (multi or single) should not be part of the DSSE protocol?

• the multi-sig verification algorithm also can't really be fully implemented by a generic DSSE implementation (because it requires checking the payload type and deserializing the payload which a generic implementation cannot do)

Why would it require checking payload type and deserializing the payload?

• the algorithm requires the implementation to break when threshold is reached: this means logging, auditing and possibly returning all valid signatures would have to be implemented somewhere else

I think that's a question of scope. The wish to log and audit all signatures in the envelope seems fair, but it is not necessarily the responsibility of the threshold sig verification routine.

[jku]

IIUC you are saying that signature verification (multi or single) should not be part of the DSSE protocol?

That is the question I'm presenting -- not really saying I know better after just a little contact with the spec

Why would it require checking payload type and deserializing the payload?

This is part of the multi-sig verification algorithm in the protocol:
Reject if PAYLOAD_TYPE is not a supported type.
Parse SERIALIZED_BODY according to PAYLOAD_TYPE. Reject if the parsing fails.

The wish to log and audit all signatures in the envelope seems fair, but it is not necessarily the responsibility of the threshold sig verification routine.

But that means I will have to implement the multi-sig verification to do it... and then I'm left wondering why I would use the multi-sig verification provided by the dsse envelope at all.

[jku]

IIUC you are saying that signature verification (multi or single) should not be part of the DSSE protocol?

That is the question I'm presenting -- not really saying I know better after just a little contact with the spec

Wait no: Single signature verification certainly does make sense in the Envelope. It's the threshold verification (aka multi-sig verification) I'm asking about

[lukpueh]

Why would it require checking payload type and deserializing the payload?

This is part of the multi-sig verification algorithm in the protocol: Reject if PAYLOAD_TYPE is not a supported type. Parse SERIALIZED_BODY according to PAYLOAD_TYPE. Reject if the parsing fails.

Oh, you are right. I don't think this is meant to be part of the signature verification routine. FWIW, those two steps are also the last two steps in the general (single-sig) protocol.

The wish to log and audit all signatures in the envelope seems fair, but it is not necessarily the responsibility of the threshold sig verification routine.

But that means I will have to implement the multi-sig verification to do it... and then I'm left wondering why I would use the multi-sig verification provided by the dsse envelope at all.

I think the spec could say something like... CAN break once threshold is reached

[lukpueh]

Wait no: Single signature verification certainly does make sense in the Envelope. It's the threshold verification (aka multi-sig verification) I'm asking about

Yeah, but you are making the argument with key (owner) semantics, which I agree, are not in the scope of DSSE.
I'm saying your argument also applies to single-sig verification, e.g. always require single sig from specific build system.

[jku]

I'm saying your argument also applies to single-sig verification, e.g. always require single sig from specific build system

oh, I am not suggesting adding any new new mechanisms to DSSE! I was giving an example some system (other than TUF or intoto) might want to create on top of DSSE.

Being able to verify if a specific key has signed the payload makes sense as an Envelope feature, but I'm questioning why a specific higher level algorithm (like multi-sig verification) would be included.