Skip to content

Update to RFC #85

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
PSUdaemon wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update to RFC #85

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 61 additions & 25 deletions rfc9246.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>
<keyword>jwt,json,token,cdn,url,http,hls,dash</keyword>

<abstract>
<t>This document describes how the concept of URI Signing supports the
Expand Down Expand Up @@ -181,7 +181,7 @@ title) for use on https://www.rfc-editor.org/search. -->
to a CDN, creating a Target CDN URI (2) (alternatively, the Target
CDN URI itself is embedded in the HTML). The Target CDN URI is the
Signed URI, which may include the IP address of the UA and/or a time
window. The signed URI always contains a signed JWT generated by the
window. The Signed URI always contains a signed JWT generated by the
CSP using a shared secret or private key. Once the UA receives the
response with the Signed URI, it sends a new HTTP request using the
Signed URI to the CDN (3). Upon receiving the request, the CDN
Expand Down Expand Up @@ -362,11 +362,14 @@ title) for use on https://www.rfc-editor.org/search. -->
<t>The following is an example where the URI Signing Package Attribute name is "token" and the signed JWT is "SIGNEDJWT":</t>


<sourcecode type=""><![CDATA[http://example.com/media/path?come=data&token=SIGNEDJWT&other=data]]></sourcecode>
<sourcecode><![CDATA[http://example.com/media/path?come=data&token=SIGNEDJWT&other=data]]></sourcecode>
<!-- [rfced] Please let us know if a "type" attribute may be added to the
sourcecode elements in this document. The allowed types can be found
here: https://www.rfc-editor.org/materials/sourcecode-types.txt
Note that it is acceptable to leave the type attribute empty.

Updated.

-->


Expand All @@ -390,7 +393,7 @@ Note that it is acceptable to leave the type attribute empty.
"mandatory" identifiers in square brackets refer to whether or
not a given claim <bcp14>MUST</bcp14> be present in a URI Signing JWT.)</t>
<t>Note: The time on the entities that generate and
verify the signed URI <bcp14>MUST</bcp14> be in sync. In the CDNI case, this
verify the Signed URI <bcp14>MUST</bcp14> be in sync. In the CDNI case, this
means that CSP, uCDN, and dCDN servers need to be
time synchronized. It is <bcp14>RECOMMENDED</bcp14> to use
<xref target="RFC5905" format="default">NTP</xref> for time synchronization.</t>
Expand All @@ -405,8 +408,8 @@ Note that it is acceptable to leave the type attribute empty.
<t>Issuer (iss) [optional] - The semantics in
<xref target="RFC7519" sectionFormat="of" section="4.1.1" format="default"/> <bcp14>MUST</bcp14> be followed.
If this claim is used, it <bcp14>MUST</bcp14> be used to identify the
issuer (signer) of the JWT. In particular, the recipient will have already
received, in trusted configuration, a mapping of issuer name to one or more
Issuer (signer) of the JWT. In particular, the recipient will have already
received, in trusted configuration, a mapping of Issuer name to one or more
keys used to sign JWTs and must verify that the JWT was signed by one of
those keys. If this claim is used and the CDN verifying the
signed JWT does not support Issuer verification, or if the
Expand Down Expand Up @@ -620,7 +623,7 @@ sectionFormat="of" section="4.1.7" format="default"/> <bcp14>MUST</bcp14> be fo
client <bcp14>SHOULD</bcp14> be directed to return the token with requests for any path. If the CDNI Signed
Token Depth is greater than zero, then the CDN <bcp14>SHOULD</bcp14> send the client a token to return for
future requests wherein the first CDNI Signed Token Depth segments of the path match the first
CDNI Signed Token Depth segments of the signed URI path. This matching <bcp14>MUST</bcp14> use the URI with the
CDNI Signed Token Depth segments of the Signed URI path. This matching <bcp14>MUST</bcp14> use the URI with the
token removed, as specified in <xref target="uri_container_forms" format="default"/>.</t>
<t>If the URI path to match contains fewer segments than the CDNI Signed Token Depth claim, a signed JWT
<bcp14>MUST NOT</bcp14> be generated for the purposes of Signed Token Renewal. If the CDNI Signed Token Depth
Expand Down Expand Up @@ -676,9 +679,12 @@ purposes only):"

Original:
[^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?

Changed below.

-->
<sourcecode><![CDATA[
[^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
[^:]*\\://[^/]*/dir/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
]]></sourcecode>
<t>Note: Due to computational complexity of executing arbitrary regular expressions, it is <bcp14>RECOMMENDED</bcp14> to only execute after verifying the JWT to ensure its authenticity.</t>
</section>
Expand Down Expand Up @@ -761,7 +767,7 @@ Original:
</section>
</section>
<section anchor="communicating_token" numbered="true" toc="default">
<name>Communicating a Signed JWTs in Signed Token Renewal</name>
<name>Communicating a Signed JWT in Signed Token Renewal</name>
<!--[rfced] Should the 's' be removed in this section title?
In other words, was singular or plural intended?

Expand All @@ -773,6 +779,9 @@ Perhaps (singular):

Or (plural):
3.3. Communicating Signed JWTs in Signed Token Renewal

Fixed.

-->
<t>This section assumes the value of the CDNI Signed Token Transport (cdnistt) claim
has been set to 1.</t>
Expand Down Expand Up @@ -949,14 +958,14 @@ in the JWT token.
</li>
</ul>
<t>The following is an example of a URI Signing metadata payload with all default values:</t>
<sourcecode><![CDATA[
<sourcecode type="json"><![CDATA[
{
"generic-metadata-type": "MI.UriSigning"
"generic-metadata-value": {}
}
]]></sourcecode>
<t>The following is an example of a URI Signing metadata payload with explicit values:</t>
<sourcecode><![CDATA[
<sourcecode type="json"><![CDATA[
{
"generic-metadata-type": "MI.UriSigning"
"generic-metadata-value":
Expand Down Expand Up @@ -1082,19 +1091,19 @@ in the JWT token.
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.CSP provides signed URI | <Positive> |
|6.CSP provides Signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.Content request | | |
|---------------------------------------->| [Verify URI |
|---------------------------------------->| [Verify URI |
| | | signature] |
| | | |
| | (ALT: Verification result) |
|8.Request is denied | <Negative>| |
|<----------------------------------------| |
| | | |
|9.Re-sign URI and redirect to <Positive>| |
| dCDN (newly signed URI) | |
| dCDN (newly Signed URI) | |
|<----------------------------------------| |
| | | |
|10.Content request | | |
Expand All @@ -1116,11 +1125,11 @@ in the JWT token.
interface, the dCDN advertises its capabilities
including URI Signing support to the uCDN.</li>
<li>CSP provides to the uCDN the information needed to
verify signed URIs from that CSP. For example, this
verify Signed URIs from that CSP. For example, this
information will include one or more keys used for validation.</li>
<li>Using the CDNI Metadata interface, the uCDN
communicates to a dCDN the information needed to
verify signed URIs from the uCDN for the given
verify Signed URIs from the uCDN for the given
CSP. For example, this information may include the URI query
string parameter name for the URI Signing Package Attribute
in addition to keys used for validation.</li>
Expand All @@ -1146,7 +1155,7 @@ in the JWT token.
provides it to the end user as the URI to use to further request the
content from the dCDN.</li>
<li>On receipt of the corresponding content request, the
dCDN verifies the Signed JWT in the signed URI using the
dCDN verifies the Signed JWT in the Signed URI using the
information provided by the uCDN in the CDNI
Metadata.</li>
<li>If the verification result is negative, the dCDN rejects the
Expand Down Expand Up @@ -1185,13 +1194,18 @@ in the JWT token.
<!-- [rfced] The acronym FCI is not expanded prior to its first use in Figure 3.
May we add its definition to the terminolgy section?

Yes.

Perhaps:
FCI: the Footprint & Capabilities Advertisement interface
-->

<!-- [rfced] This document uses "FCI interface" despite "interface" being
represented in the acronym itself. May we remove "interface" after both
intstances of FCI?

Yes.

-->
<figure anchor="fig_dns_routing">
<name>DNS-based Request Routing with URI Signing</name>
Expand All @@ -1218,7 +1232,7 @@ intstances of FCI?
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.Provides signed URI | <Positive> |
|6.Provides Signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.DNS request | | |
Expand Down Expand Up @@ -1787,13 +1801,18 @@ of RFC 9246
<!-- [rfced] In the following sentence, what is the intended expansion for
"LRU"? Is "Least Recently Used (LRU) value" correct?

Yes.

Original:
If no exp claim is present then a simple LRU could be
used, however this would allow values to eventually be reused.

Perhaps:
If no exp claim is present, then a simple Least Recently Used (LRU)
value could be used; however, this would allow values to eventually be reused.

This is fine.

-->
</dd>

Expand Down Expand Up @@ -1908,6 +1927,8 @@ Perhaps:
this be used instead of the current 2014 version (which has been
withdrawn)?

Yes.

Current:
[MPEG-DASH]
ISO, "Information technology - Dynamic adaptive streaming
Expand Down Expand Up @@ -1935,10 +1956,10 @@ Current:
<t>This section contains three examples of token usage: a simple example with only the
required claim present, a complex example that demonstrates the full JWT claims set,
including an encrypted Client IP Address (cdniip), and one that uses a Signed Token Renewal.</t>
<t>Note: All of the examples have whitespace added to improve formatting and readability,
<t>Note: All of the examples have empty space added to improve formatting and readability,
but are not present in the generated content.</t>
<t>All examples use the following JWK Set <xref target="RFC7517" format="default"/>:</t>
<sourcecode><![CDATA[
<sourcecode type="json"><![CDATA[
{ "keys": [
{
"kty": "EC",
Expand Down Expand Up @@ -1992,13 +2013,18 @@ place a line break in this line?

Current:
"cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"

Changed:
"cdniuc":
"hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
-->

<sourcecode><![CDATA[
<sourcecode type="json"><![CDATA[
{
"exp": 1646867369,
"iss": "uCDN Inc",
"cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
"cdniuc":
"hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
}
]]></sourcecode>
<t>
Expand Down Expand Up @@ -2039,7 +2065,7 @@ F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g
<t>
The JWT Claim Set before signing:
</t>
<sourcecode><![CDATA[
<sourcecode type="json"><![CDATA[
{
"aud": "dCDN LLC",
"sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4
Expand Down Expand Up @@ -2085,7 +2111,7 @@ jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w
<t>
The JWT Claim Set before signing:
</t>
<sourcecode><![CDATA[
<sourcecode type="json"><![CDATA[
{
"cdniets": 30,
"cdnistt": 1,
Expand Down Expand Up @@ -2114,7 +2140,7 @@ HYw
<t>
The JWT Claim Set before signing:
</t>
<sourcecode><![CDATA[
<sourcecode type="json"><![CDATA[
{
"cdniets": 30,
"cdnistt": 1,
Expand Down Expand Up @@ -2160,9 +2186,16 @@ document. Please let us know which form, if any, is preferred.

signed URI vs. Signed URI

Signed URI

issuer vs. Issuer

It should be Issuer

JSON object vs. JSON Web Encryption Object

I think the two different uses are correct.

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Expand All @@ -2171,6 +2204,9 @@ and let us know if any changes are needed.

For example, please consider whether the following should be updated:
"whitespace"

Changed to "empty space"

-->


Expand Down