Is the section on "encryption file" too brief?

[KikkiZ]

Section

https://w3c.github.io/epub-specs/epub34/authoring/#sec-container-metainf-encryption.xml

Describe the problem

OCF uses XML Encryption [xmlenc-core1] to provide a framework for encryption, allowing a variety of algorithms to be used.

"Encryption" uses the XML encryption framework, but is this framework too broad for resource encryption?
Furthermore, the "encryption file" section doesn't provide many constraints on this file, which might cause definitional confusion.

(I'm not sure if the "encryption" feature is widely used; perhaps it's an infrequently used feature, leading to incomplete specifications.)

Describe the fix or new feature you propose

No response

[iherman]

I believe the definition of that file (and the others in the same section) is deliberately open to allow for several different applications to be used. Specific applications are supposed to fill in the gaps for their own use.

Specifically, the encryption.xml file is used, afaik, by several DRM schemes (like LCP, cc-ing @llemeurfr in case I am wrong). By their very nature, these schemes define the details for their own use. Note that by charter, this Working Group does not work on DRM or other encryption schemes.

I would therefore leave things as is.

@mattgarrish

[mattgarrish]

Right, with the meta-inf files we typically don't wade too far into how implementors have to use them since that's not in our scope. DRM is more typically associated with the rights.xml file, which we don't detail at all.

Encryption.xml is a component of drm, but we had to detail the file, at a minimum, for font obfuscation. It's not really for authors beyond that use case, and, as you say, implementors already control what they're doing in terms of encrypting resources. So, I suspect while we might be able to subset the full scope of the specification, it's also probably not meaningful for implementors for us to do that.

The one external case I can think of for handling encrypted files when you didn't have a hand in the encryption is running the files through epubcheck, but as far as I'm aware it just ignores all encrypted content. And I don't expect that would change no matter what is done here.

[llemeurfr]

Yes, Readium LCP (an ISO standard, the greatest DRM for ebooks and audiobooks in the world, used worldwide, replacing old crappy solutions, contact EDRLab to know more ;-) ) defines the specifics of the use of encryption.xml in its context.

Details on the Readium LCP specification,
and especially the section on encryption.xml.

Note that LCP does not make any use of rights.xml; constraints are expressed in a JSON license structure.

[iherman]

Based on the comments/responses, I propose to close the issue.