Allow signing the components of a package

[llemeurfr]

The new packaging format should not mix xml with json. Therefore the reuse of the signature.xml file is not the way to go and we have to find a "json" way to handle the signature of WP resources.

[iherman]

I am not an expert in this area, but I stumbled across these references:

• JSON Web Signature (JWS): "JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification."

• JSON Web Algorithms (JWA): "This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers."

• JSON Web Key (JWK): "A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification."

• JSON Web Encryption (JWE): "JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification."

These are all proposed RFC standards. Bottom line: there are a number of JSON-based specifications that could be used...

[dauwhe]

How many creators of EPUB sign their EPUBs? Do any existing audiobook workflows or formats involve digitally signing the files? Blackstone's format does provide a way to record the hash of the individual audio files... is this enough for existing uses?

[GarthConboy]

At least for now [audiobooks] (and likely long term), I'd just expunge signature.xml.

[geoffjukes]

We (Blackstone) do not digitally sign our audio or epubs. We do (as @dauwhe mentions) gather an MD5, which is used by our apps to validate a download is complete. Could be facilitated with w3c/wpub#398 ?

[iherman]

I have a preference for something like https://github.com/w3c/wpub/issues/398, just as @geoffjukes proposes. Having yet another separate file sounds over the top; having slots in the metadata file for some sort of a checksum sounds reasonable (and also mimics what happens elsewhere).

[laudrain]

@dauwhe actually at Hachette Livre digital distribution, we do sign our EPUBs and send the MD5 in the ONIX feed describing the file. That's systematic.

[BigBlueHat]

A signature of the JSON won't be a signature of the package nor its contents, so the scenarios and moment of verification should be considered thoroughly.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions
  View the transcript

  1.3. signature
  Laurent Le Meur: https://github.com/w3c/pwpub/issues/31
  Laurent Le Meur: There is one thing we could possibly discuss. Issue 31 about signatures. It seems there is a sort of consensus in OCF - there is a notion of signature in the package.
  … Maybe it would be better to use MD5 or hash to the resources, and not pretend to sign the document. We have to choose between these two levels. We either want security for the node, or signature as an anti-hacking proof.
  Tzviya Siegman: Wendy - was this one item you wanted to discuss as a larger issue?
  Wendy Reid: Yes, this is a spec issue and not exclusive to audiobooks.
  Tzviya Siegman: While it primarily effects packaging, it can be done in a non-packaged wpub, so it’s an issue that’s already on the wpub tracker.
  Ivan Herman: related to https://github.com/w3c/wpub/issues/398
  Dave Cramer: https://www.w3.org/TR/SRI/
  Tzviya Siegman: Lets address this next week or the following week.
  Laurent Le Meur: OK - we’ll see that later.
  

[llemeurfr]

Proposal:

• consider that there is no urgent need to standardize a signature mechanism for packaged web publications. Even if some publishers are signing EPUBs today (see @laudrain's comment above) there is no evidence that recipients check the signature. A signature mechanism will be easily added to the solution if a proper use case arises.
• consider that digests on individual resources (as discussed in the wpub spec) constitue a good way to control that they are complete in a package.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Don’t define a signature mechanism (certainly not signature.xml!)
  View the transcript

  Allow signing the components of a package
  Garth Conboy: https://github.com/w3c/pwpub/issues/31
  Laurent Le Meur: Issue is #31 - proposal is to do nothing.
  … In OCF there was a signature and a definition about not using something complex - but to use hash mechanism of resources as a way to show completeness
  Proposed resolution: Don’t define a signature mechanism (certainly not signature.xml!) (Garth Conboy)
  Laurent Le Meur: it seems we do not need to define any additional information
  Garth Conboy: +1
  Joshua Pyle: +1 to no signature mechanism
  Laurent Le Meur: +1
  Garth Conboy: I put a proposal matching what laurent just said.
  Nick Ruffilo: +1 to no signature mechanism
  Brady Duga: +1
  Dave Cramer: +1
  Dave Cramer: I would note that epub has this mechanism but the community group was opposed to putting any requirements on this - so you could have an invalid signature and things still display to the reader…
  Ben Schroeter: +1
  Ivan Herman: +1
  Ric Wright: +1
  Resolution #5: Don’t define a signature mechanism (certainly not signature.xml!)
  Deborah Kaplan: +1
  

[llemeurfr]

no update needed.