Use Case: Signing RO-Crates

[FlorianRhiem]

As a software developer, I want to provide a signature along with RO-Crates my software exports so that users can verify that the RO-Crate is from my software and hasn't been altered by a third party.

The context for this is the .eln file format which is built on top of RO-Crate. To ensure that data exported by one ELN and imported into another has not been modified and has actually been exported by that other ELN and not by a third party, we would like to provide a signature of some kind along with the RO-Crate. We've gathered some ideas in an issue on the topic there, however this use case might be of interest for RO-Crates in general and a solution independent of the .eln file format might be found.

[jmfernandez]

As a partial solution, an RO-Crate bundled in a zip file could be signed using https://github.com/falk-werner/zipsign or a similar solution. But, other scenarios where the RO-Crate is bundled using tar, rar, or other archive software would not be covered by this.

[FlorianRhiem]

ZipSign seems to combine the OpenSSL implementation of Cryptographic Message Syntax (CMS) to generate and verify the signature and zip comments to store/retrieve the signature. If formats other than zip should be supported, then the openssl cms command could be used directly to sign/verify the signature and the signature could be placed either in a file at a well-known path relative to the ro-crate-metadata.json or a file at a path referenced by the ro-crate-metadata.json. This would also have the advantage that openssl itself is rather widely available.

[stain]

Thanks for raising this requirement!

We were thinking about this requirement also in Five Safes RO-Crate. You may found the Security considerations helpful. We didn't however settle on the mechanism for cryptographic signatures.

There we rely on the optional BagIt packaging which moves the crate to data/ and then adds checksums files manifest-sha512.txt and tagmanifest-sha512.txt -- a cryptographic signature would then only need to be done on tagmanifest-sha512.txt to cover the whole RO-Crate file-wise, assuming clients also check the BagIt checksums as we recommend in 5s-crate. In order to also have signature on external resources you would need to embed their checksum within the ro-crate-metadata.txt (e.g. with http://schema.org/sha256) or use the fetch.txt part of BagIt.

[simontaurus]

Why not use Verifiable Credentials (wikipedia) to sign the ro-crate-metadata.json? If it's mandatory to include the checksum of every (uncompressed) file in ro-crate-metadata.json for a signed RO-Crate there's no need to sign the compressed archive. In addition this would work also for remote file. Draft example using a RSA JWS as proof

{ "@context": [
    "https://w3id.org/ro/crate/1.1/context",
    "https://www.w3.org/ns/credentials/v2"
  ],
  "@graph": [
    {
      "@type": "CreativeWork",
      "@id": "ro-crate-metadata.json",
      "conformsTo": {"@id": "https://w3id.org/ro/crate/1.1"},
      "about": {"@id": "./"}
    },  
    {
      "@id": "./",
      "@type": [
        "Dataset"
      ],
      "hasPart": [
        { "@id": "cp7glop.ai" }
      ]
    },
    {
      "@id": "cp7glop.ai",
      "@type": "File",
      "name": "Diagram showing trend to increase",
      "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
    },
    {
        "@id": "http://example.edu/credentials/3732",
        "@type": ["VerifiableCredential", "RoCrateCredential"],
        "issuer": "https://example.edu/issuers/14",
        "issuanceDate": "2010-01-01T19:23:24Z",
        "credentialSubject": "ro-crate-metadata.json",
		"proof": {
			"created": "2021-05-17T15:25:26Z",
			"jws": "eyJhbGciOiJFZERTQYjY0Il19..nlcAA",
			"verificationMethod": "https://pathToIssuerPublicKey"
		}
  ]
}