Chain of endorsement - assumptions and open questions

[nt-gt]

• Q: [Endorsement chain]: How do the transport document compose with endorsement chain signatures?

Assume that T owns the transport document Doc and wants to sell it on to E. In the physical world, T and E both signs the back side of the Doc and then E takes the document with them.

The question is how this to be reflected in the digital world?

• Should T modify Doc to state that E is the new owner and then sign that?
• Should T sign some form of statement "I known Doc and have agreed to passe it on to E on date X"?

Either way, how do we reliably restructure the Endorsement chain so we can tell that E is the true owner of the contents (and that T did not sell Doc twice)? I think we are missing some concrete format that is covered by a signature but still machine readable to ensure it can be validated easily.

Proposal:

I think we should look at this from two angles that should be supported side by side.

1. The Endorsement chain link is an unstructured blob: This occurs for any physical BL / TD that is converted into an electronic version (e.g. by scanning the physical version into a PDF/zip of images). The advantage of this is that it works for anything but at the cost of requiring human verification (i.e. the system can validate the signature of the blob but a human is needed to validate it and extract structured format from it).
2. The Endorsement chain link is in a structured format: This happens for any endorsement chain links where the BL / TD are electronic but also for further updates in an Endorsement chain that that has been converted from physical to electronic format. In this format, we can machine validate the link 100% enabling automation for all parties involved.

Both variants need to be signed.

The structured Endorsement chain link format need to assert:
- That this is an endorsement / ownership transfer (can be implicit in the format).
- Who is the title holder (can be implicit from the signature)
- Who is the endorsee. _Does the endorsee need to sign this as well? _
- Legal time of ownership transfer (endorsement_datetime)
- A reference to the previous part of the endorsement chain link (to build the chain).
- The transport document (might be implicit in the above)
- If the endorsee also needs to sign the link, then we need to study this in more detail. Also, there is an open question if / how notary services play into this.

• Q: [Key mgmt]: When a shipper/carrier rotates their key, how will we handle signatures from the old key?

Currently, we only have one public key per party and no "link" from the signature to the public key that signed it.

• If you replace the public key on the party object in the IM, then old signatures cannot be validated (as you are now using the wrong key).

• If you do not replace the public key on the party object and instead create a new party object with a distinct UUID, then references by Party ID will keep using the old key even after it has been rotated (i.e. you have to tell every one to stop using the old Party ID as the party will not be using the public key related to that party).

• Assumption: X.509 certificates

Public keys will be based on X.509 certificates. The standard is well known and ensures we know which signature algorithm is used for signing (as X.509 includes a signing algorithm).

• If this assumption does not hold then we should find a model where we can solve all this. Furthermore, we might need IM changes to store the signature algorithm if the new scheme does not make that a part of the public key OR the signature itself.
• If the assumption holds then how does the public key field in the database interact with the PKI/CA model (if at all)?

Note this assumption cannot be invalid if "technology agnostic" also covers the public key/signature algorithm. However, in that case, the spec is inadequate for use in practice (as it does not cover key expiry, key rotation, key revocation, signature algorithms). Anyone implementing that spec would either de facto be forced to use something like X.509 or "invent their own crypto" (which is the top item on the list of "Do not ever do this if you want this to be secure")

[raisoman]

Adding some context:

Our current POC-to-be of the electronic transfer of title at DCSA consists of modelling an endorsement chain as follows:

We assume we have document (a BL) either as a binary blob or a structured document (json). Each time the title is transferred, simply append a signed "endorsement chain link" to it. In practice we would thus build up a collection of files, with the first file being the BL and the subsequent files being endorsing signatures of all the previous files concatenated. This is in essence a replication of the current paper-based process as-is.

[nt-gt]

Just to confirm, is it the same underlying document in the chain? As in, do we view it as a O || S1 || S2 || ... || Sn (where O is the original document, and the S1 etc. are signatures and || being a binary concat operation)?

If so, I think we need to answer the following questions:

1. Given a bytestream of a document with all of its signatures, how do I know where the original document ends (O) and the signatures start (S1 || S2 || ... || Sn), so I can read the original document (e.g. PDF readers and Json parsers will reject files with the trailing signatures).
2. Given the bytestream of S1 || S2 || ... || Sn, how do I split it into a list of [S1, S2, ..., Sn] such that I can validate each part of the chain? (Alternative variant can be how do I reliably pop a signature from that string as you always want to read it right-to-left if you validate signatures)

The first item is required to read the actual document, so they know what the document says. The second is required to validate the chain of endorsement.