From 347d237c25db7f7e0bc16bfdc292770ea7226a45 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 10:39:16 +0200 Subject: [PATCH 1/9] Fix issues raised by Murata M. --- releases/lcp/latest.md | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/releases/lcp/latest.md b/releases/lcp/latest.md index 37528a0..7e2a6db 100644 --- a/releases/lcp/latest.md +++ b/releases/lcp/latest.md @@ -628,7 +628,7 @@ Given the importance of the precise expression of various objects in the License Calculating a signature is done on a byte stream, which is unique, while the License Document is a JSON document where multiple representations might lead to the same structure. Thus, to ensure a stable signature between the Reading System and the Content Provider, some transformations must be applied prior to signing the Document and verifying the signature. -The steps required of the Provider to sign the License Document are: +The steps required from the Provider to sign the License Document are: 1. The contents of the License Document (minus the signature object) are put in a canonical form: alphabetized with non-significant whitespace removed (see [Section 5.3](#53-canonical-form-of-the-license-document)) @@ -670,15 +670,15 @@ Reading Systems must obtain the Root Certificate in the [[X50 The canonical form of the License Document is used when calculating and validating the signature. To create the canonical form of the License Document, the following serialization rules must be followed: -1. Since it is product of the calculation, the `signature` object of the License Document must be removed. +1. Since the `signature` object of the License Document is the product of the calculation, it must be removed. -2. All object members (name/value pairs) of the License Document must** **be sorted in lexicographical order of their names according to their representation in UTF-8 (United Character Set code point value). Note that this rule is recursive, so that members are sorted at all levels of object nesting. +2. All object members (name/value pairs) of the License Document must be sorted in lexicographical order of their names according to their representation as Unicode code point. Note that this rule is recursive, so that members are sorted at all levels of object nesting. 3. Within arrays, the order of elements must not be altered. 4. Numbers must not include insignificant leading or trailing zeroes. Numbers that include a fraction part (non-integers) must be expressed as a number, fraction, and exponent (normalized scientific notation) using an upper-case "E". -5. Strings must use escaping only for those characters for which it is required by [[JSON](#normative-references)]: backslash (\), double-quotation mark ("), and control characters (U+0000 through U+001F). When escaping control characters, the hexadecimal digits must be upper case. +5. Strings must use escaping only for those characters for which it is required by [[JSON](#normative-references)]: backslash (\\), double-quotation mark ("), and control characters (U+0000 through U+001F). When escaping control characters, the hexadecimal digits must be upper case. 6. Non-significant whitespace (as defined in [[JSON](#normative-references)]) must be removed. Whitespace found within strings must be kept. @@ -786,7 +786,7 @@ q/3IInic9c/EaJHyG1Kkqk5v1zlJNsiQBmxz4lykhyD3dA2jg2ZzrOenYU9GxP/xhe5H5Kt2WaJ/hnt8 ``` -With this signature and the certificate, a valid license may be created: +With this signature and the certificate, a valid license will be created as e.g.: ```json { @@ -822,11 +822,13 @@ With this signature and the certificate, a valid license may #### **5.5.1. Validating the certificate** -1. It must check that the Certificate was not expired when the License Document was last updated. +1. The Reading System must check the signature of the Provider Certificate using the Root Certificate it embeds. -2. It must validate the presence of the Provider Certificate in the root chain. To do so, it must check the signature of the Provider Certificate using the public key of the Root Certificate. +2. If a network connection is available, it must periodically update its Certificate Revocation List, as defined in [[X509](#normative-references)]. -3. It must validate that the certificate was not revoked as defined in [[X509](#normative-references)]. If a network connection is available, it must update its certificate revocation list before it checks the validity of the certificate. +3. It must check that the Certificate was not revoked, as defined in [[X509](#normative-references)]. + +4. It must check that the Certificate was not expired when the License Document was last updated. #### **5.5.2. Validating the signature** @@ -847,7 +849,7 @@ In order to validate the signature, the following steps must LCP is entirely based on standard encryption algorithms, as defined in [[XML-ENC](#normative-references)] and [[XML-SIG](#normative-references)]. In order to maintain maximum flexibility, no specific algorithms are mandated by this specification. Instead, the design of both `encryption.xml` and the License Document allow for the identification of encryption algorithms to be discovered by Reading Systems when presented with a Protected Publication. -In order to simplify this discovery process, the LCP 1.0 specification defines an Encryption Profile, which is the set of encryption algorithms used in a specific Protected Publication and associated Licence Document. Reading Systems that implement the algorithms identified in the Encryption Profile will be able to decrypt Protected Publications encoded using that Encryption Profile. For ease of discovery, the Encryption Profile is identified in the License Document. +In order to simplify this discovery process, LCP defines an Encryption Profile, which is the set of encryption algorithms used in a specific Protected Publication and associated Licence Document. Reading Systems that implement the algorithms identified in the Encryption Profile will be able to decrypt Protected Publications encoded using that Encryption Profile. For ease of discovery, the Encryption Profile is identified in the License Document. This specification defines the Basic Encryption Profile 1.0, along with a list of associated algorithms extracted from [[XML-ENC](#normative-references)] or [[XML-SIG](#normative-references)]. All future official or vendor-specific extensions will also define such an Encryption Profile for easy identification by Reading Systems and publish such profiles in the [LCP Encryption Profiles Registry](#informative-references). @@ -863,11 +865,11 @@ All Encryption Profiles must identify algorithms for the foll 4. Signature -All algorithms used in an Encryption Profile must be defined in [[XML-ENC](#normative-references)] or [[XML-SIG](#normative-references)]. +All algorithms used in an Encryption Profile should be defined in [[XML-ENC](#normative-references)] or [[XML-SIG](#normative-references)]. All Encryption Profiles must use a URI to identify themselves in `profile` (contained in the `encryption` object of the License Document). -All Encryption Profiles must be registered in the LCP Encryption Profiles registry, as explicitly explained in the registry. +All Encryption Profiles must be registered in the LCP Encryption Profiles registry. ## 6.3. Basic Encryption Profile 1.0 @@ -998,7 +1000,7 @@ Reading Systems must not: * [LCP Link Relations Registry](https://readium.org/lcp-specs/registries/relations) * [LCP Rights Registry](https://readium.org/lcp-specs/registries/rights) * [LCP User Fields Registry](https://readium.org/lcp-specs/registries/user) -* LCP Encryption Profiles Registry +* [LCP Encryption Profiles Registry](https://readium.org/lcp-specs/registries/profiles) ## Apendix A. JSON Schema From 2e71cf14eb18fef2be35ce11a44a2630c79fefff Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 10:39:43 +0200 Subject: [PATCH 2/9] Add Encryption Profiles registry --- registries/profiles.md | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 registries/profiles.md diff --git a/registries/profiles.md b/registries/profiles.md new file mode 100644 index 0000000..0b2382a --- /dev/null +++ b/registries/profiles.md @@ -0,0 +1,6 @@ +# Readium LCP Encryption Profiles Registry + +| Identifier | Description | Reference | +| -------- | --------- | --------- | +| `http://readium.org/lcp/basic-profile` | Basic Encryption Profile 1.0, used for testing purpose only | [Readium LCP specification](https://readium.org/lcp-specs/readium-lcp-specification) | +| `http://readium.org/lcp/profile-1.0` | Production Encryption Profile 1.0, defined by EDRLab | [EDRLab website](https://www.edrlab.org/readium-lcp/) | From 446a0aefda9812d57da3303e9b6615b3e82e3fe8 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 10:39:57 +0200 Subject: [PATCH 3/9] Remove CSS from file --- releases/lsd/latest.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/releases/lsd/latest.md b/releases/lsd/latest.md index b0a76e7..8806c5a 100644 --- a/releases/lsd/latest.md +++ b/releases/lsd/latest.md @@ -449,12 +449,3 @@ A JSON Schema for LSD 1.0 is available under version control at [https://github. For the purpose of validating a status document, use the following JSON Schema resource: [https://readium.org/lcp-specs/schema/status.schema.json](https://readium.org/lcp-specs/schema/status.schema.json) - - From 148a1f2e261018311a48298c9dc0099be374dad0 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 11:01:19 +0200 Subject: [PATCH 4/9] Fixes #19 using D.Weck's proposal --- releases/lcp/latest.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/lcp/latest.md b/releases/lcp/latest.md index 7e2a6db..a9a1809 100644 --- a/releases/lcp/latest.md +++ b/releases/lcp/latest.md @@ -672,7 +672,7 @@ The canonical form of the License Document is used when calculating and validati 1. Since the `signature` object of the License Document is the product of the calculation, it must be removed. -2. All object members (name/value pairs) of the License Document must be sorted in lexicographical order of their names according to their representation as Unicode code point. Note that this rule is recursive, so that members are sorted at all levels of object nesting. +2. All JSON object properties (i.e. key/value pairs) in the License Document must be lexicographically sorted by Unicode Code Point. Note that this rule is recursive, so that members are sorted at all levels of object nesting. 3. Within arrays, the order of elements must not be altered. From b46673ed9b07176742aefc7e4dd5dad8e19d4bd8 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 11:16:19 +0200 Subject: [PATCH 5/9] gitignore Gemfile --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 45c1505..3ab5a7c 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,6 @@ _site .sass-cache .jekyll-metadata +Gemfile +Gemfile.lock + From 006e799829fc0493027a7d239ea85f2fe9adcf69 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 11:16:41 +0200 Subject: [PATCH 6/9] correct registry links --- registries/README.md | 2 +- registries/profiles.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/registries/README.md b/registries/README.md index 153f2d5..7943182 100644 --- a/registries/README.md +++ b/registries/README.md @@ -3,4 +3,4 @@ - [LCP Link Relations Registry](relations.md) - [LCP Rights Registry](rights.md) - [LCP User Fields Registry](user.md) -- LCP Encryption Profiles Registry +- [LCP Encryption Profiles Registry](profiles.md) diff --git a/registries/profiles.md b/registries/profiles.md index 0b2382a..69d079c 100644 --- a/registries/profiles.md +++ b/registries/profiles.md @@ -2,5 +2,5 @@ | Identifier | Description | Reference | | -------- | --------- | --------- | -| `http://readium.org/lcp/basic-profile` | Basic Encryption Profile 1.0, used for testing purpose only | [Readium LCP specification](https://readium.org/lcp-specs/readium-lcp-specification) | +| `http://readium.org/lcp/basic-profile` | Basic Encryption Profile 1.0, used for testing purpose only | [Readium LCP specification](../releases/lcp/latest.md) | | `http://readium.org/lcp/profile-1.0` | Production Encryption Profile 1.0, defined by EDRLab | [EDRLab website](https://www.edrlab.org/readium-lcp/) | From 6938de44bee00785438ccc090bc11072fa28e41c Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 13:11:53 +0200 Subject: [PATCH 7/9] Fix header links --- _config.yml | 2 +- _includes/header.html | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/_config.yml b/_config.yml index 350fd5e..06808e3 100644 --- a/_config.yml +++ b/_config.yml @@ -17,7 +17,7 @@ title: Readium LCP - ebook DRM author: EDRLab email: contact@edrlab.org description: Specifications and extensions of the Readium LCP DRM. -url: "https://readium.org/lcp-specs/" # the base hostname & protocol for your site +url: "https://readium.org/lcp-specs" # the base hostname & protocol for your site section: /lcp-specs/ # URL part to be added to links in production # Build settings diff --git a/_includes/header.html b/_includes/header.html index 8b2f6dc..8b85ab5 100644 --- a/_includes/header.html +++ b/_includes/header.html @@ -21,9 +21,9 @@
Intro - LCP - LSD - Codebase + LCP + LSD + Codebase
{%- endif -%} From 472042f22f7fce2c514e99bea9d6123c7702961d Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Fri, 30 Aug 2019 13:16:12 +0200 Subject: [PATCH 8/9] remove property site.section --- README.md | 2 +- _config.yml | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index 7fc22a8..6609642 100644 --- a/README.md +++ b/README.md @@ -59,7 +59,7 @@ Other requirement papers are: ## Software -A large [open-source codebase]({{site.section}}readium-lcp-codebase/) has been developed as part of the Readium project by EDRLab. This includes a full featured License Server, DRM libraries compliant with different Readium toolkits (Readium SDK, Readium Mobile / Desktop), plus a lightweight library which can be integrated on any device. +A large [open-source codebase]({{site.url}}/readium-lcp-codebase/) has been developed as part of the Readium project by EDRLab. This includes a full featured License Server, DRM libraries compliant with different Readium toolkits (Readium SDK, Readium Mobile / Desktop), plus a lightweight library which can be integrated on any device. ## More Information diff --git a/_config.yml b/_config.yml index 06808e3..d66a7d4 100644 --- a/_config.yml +++ b/_config.yml @@ -18,7 +18,6 @@ author: EDRLab email: contact@edrlab.org description: Specifications and extensions of the Readium LCP DRM. url: "https://readium.org/lcp-specs" # the base hostname & protocol for your site -section: /lcp-specs/ # URL part to be added to links in production # Build settings markdown: kramdown From 058c14853a8e9fb2275c62fd6a14876146c9e1d6 Mon Sep 17 00:00:00 2001 From: Laurent Le Meur Date: Tue, 3 Sep 2019 10:51:29 +0200 Subject: [PATCH 9/9] update of the intro to the Encryption Profile registry. Deletion of a sentence making registries normative in the spec. --- releases/lcp/latest.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/releases/lcp/latest.md b/releases/lcp/latest.md index a9a1809..13cd469 100644 --- a/releases/lcp/latest.md +++ b/releases/lcp/latest.md @@ -826,9 +826,9 @@ With this signature and the certificate, a valid license will be created as e.g. 2. If a network connection is available, it must periodically update its Certificate Revocation List, as defined in [[X509](#normative-references)]. -3. It must check that the Certificate was not revoked, as defined in [[X509](#normative-references)]. +3. The Reading System must check that the Certificate was not revoked, as defined in [[X509](#normative-references)]. -4. It must check that the Certificate was not expired when the License Document was last updated. +4. The Reading System must check that the Certificate was not expired when the License Document was last updated. #### **5.5.2. Validating the signature** @@ -836,11 +836,11 @@ In order to validate the signature, the following steps must 1. The Reading System must extract and remove the signature from the License Document. -2. It must calculate the canonical form of the License Document following the rules as expressed in [5.3. Canonical form of the License Document](#53-canonical-form-of-the-license-document). +2. The Reading System must calculate the canonical form of the License Document following the rules as expressed in [5.3. Canonical form of the License Document](#53-canonical-form-of-the-license-document). -3. It must recalculate the signature as defined in [5.4. Generating the signature](#54-generating-the-signature). +3. The Reading System must recalculate the signature as defined in [5.4. Generating the signature](#54-generating-the-signature). -4. It must verify that the calculated signature value is consistent with the one previously extracted from the License Document. +4. The Reading System must verify that the calculated signature value is consistent with the one previously extracted from the License Document. # 6. Encryption Profiles @@ -849,9 +849,11 @@ In order to validate the signature, the following steps must LCP is entirely based on standard encryption algorithms, as defined in [[XML-ENC](#normative-references)] and [[XML-SIG](#normative-references)]. In order to maintain maximum flexibility, no specific algorithms are mandated by this specification. Instead, the design of both `encryption.xml` and the License Document allow for the identification of encryption algorithms to be discovered by Reading Systems when presented with a Protected Publication. -In order to simplify this discovery process, LCP defines an Encryption Profile, which is the set of encryption algorithms used in a specific Protected Publication and associated Licence Document. Reading Systems that implement the algorithms identified in the Encryption Profile will be able to decrypt Protected Publications encoded using that Encryption Profile. For ease of discovery, the Encryption Profile is identified in the License Document. +In order to simplify the discovery process, LCP defines the notion of Encryption Profile, which is the set of encryption algorithms used in a specific Protected Publication and associated Licence Document. Reading Systems that implement the algorithms identified in the Encryption Profile will be able to decrypt Protected Publications encoded using that Encryption Profile. The identification of the Encryption Profile in the License Document eases the discovery of these requirements by Reading Systems. -This specification defines the Basic Encryption Profile 1.0, along with a list of associated algorithms extracted from [[XML-ENC](#normative-references)] or [[XML-SIG](#normative-references)]. All future official or vendor-specific extensions will also define such an Encryption Profile for easy identification by Reading Systems and publish such profiles in the [LCP Encryption Profiles Registry](#informative-references). +This specification defines the Basic Encryption Profile 1.0, composed from a set of associated algorithms extracted from [[XML-ENC](#normative-references)] or [[XML-SIG](#normative-references)]. The Basic Encryption Profile is for test only, as it does not provide the level of obfuscation required by a reliable protection mechanism. + +Other Encryption Profiles are (or will be) defined for use in production; these profiles are referenced in the [LCP Encryption Profiles Registry](#informative-references). ## 6.2. Encryption Profile Requirements @@ -869,8 +871,6 @@ All algorithms used in an Encryption Profile should be define All Encryption Profiles must use a URI to identify themselves in `profile` (contained in the `encryption` object of the License Document). -All Encryption Profiles must be registered in the LCP Encryption Profiles registry. - ## 6.3. Basic Encryption Profile 1.0 Basic Encryption Profile 1.0 is identified in the `encryption` object of the License Document using the URL `http://readium.org/lcp/basic-profile` for the `profile` attribute value.