URI Signing for Content Delivery Network Interconnection (CDNI)
draft-ietf-cdni-uri-signing-26

[Ballot comment]
Thank you (new for -26) for finalizing the switch to "MUST NOT"
redistribute symmetric keys!

Thank you for lowering the prominence of the cdniip claim/functionality,
it is much appreciated.

Thank you as well for updating the examples; I am too crunched for time to
attempt to revalidate them before the AD cutover, but am happy to see
that they were updated.

I also appreciate the additional text covering the JWT "iss" usage and
reinforcing that a key used to sign JWTs (regardless of whether it is
identified using "iss") must be delivered in trusted configuration (i.e.,
not in-band).  I would have preferred to see this point reiterated in the
Security Considerations, as much of the new text is in the description of
the usage of the "iss" claim (which one might expect to be irrelevant if
the claim itself is not being used), but that is no longer a Discuss-level
point based on the updates elsewhere in the document.

[Ballot discuss]
I see that the -25 has demoted discussion of symmetric key redistribution
from (paraphrasing) "a normal thing mentioned in passing" to a SHOULD NOT
action.  This is a step in the right direction, but I am not sure that
it's far enough.  Is there some additional background on why this
functionality (of key redistribution from uCDN to dCDN in particular, or
group sharing of a single symmetric key from CSP to both uCDN and dCDN) is
required to retain that I am failing to find?  The latest discussion I see
in the WG email archives is
https://mailarchive.ietf.org/arch/msg/cdni/iFP6w3z22yQ1s0IJisrsIJN1ikU/
which seemed to suggest that the mechanism would be removed entirely.
The security properties of this group key sharing are sufficiently poor
that (if we do need to keep it) I think there would need to be explicit
discussion in the document about what the use case is and why that use
case allows for the weakening of security properties.

[Ballot comment]
Thank you for lowering the prominence of the cdniip claim/functionality,
it is much appreciated.

Thank you as well for updating the examples; I am too crunched for time to
attempt to revalidate them before the AD cutover, but am happy to see
that they were updated.

I also appreciate the additional text covering the JWT "iss" usage and
reinforcing that a key used to sign JWTs (regardless of whether it is
identified using "iss") must be delivered in trusted configuration (i.e.,
not in-band).  I would have preferred to see this point reiterated in the
Security Considerations, as much of the new text is in the description of
the usage of the "iss" claim (which one might expect to be irrelevant if
the claim itself is not being used), but that is no longer a Discuss-level
point based on the updates elsewhere in the document.

[Ballot discuss]
Thanks for the updates in the -22 through -24.  I think a couple of my
discuss points remain at the discuss level, which I'll expound on a bit more
below.

I am happy to see the pervasive disclaimers that use of a symmetric shared
key is supported but NOT RECOMMENDED, and the note that redistribution of
the symmetric shared key to dCDNs (including cascaded CDNs) is included for
legacy feature parity and highly discouraged in new implementations.
However, I think this does not fully address my original discuss point.  As
I said then, [[I see a minimal acknowledgment that there is potential cause
concern in the penultimate paragraph of the security considerations that "it
is important to know the implications of a compromised shared key", but in
my mind the text there does not really call out the severity of those
implications.  I would have expected something like "redistributing the
shared key in this manner allows the dCDNs to impersonate the CSP to the
uCDN and produce arbitrary signed URLs that are accepted by the uCDN as
authentic".]]  In particular, I think it is important to emphasize in some
manner that the cryptographc properties of the symmetric shared key are
fully symmetric across all participants, even though the administrative and
organizational structure here is hierarchical with explicitly more- and
less-trusted entities, making the symmetric cryptographic mechanism a
mismatch for the desired trust boundaries and inviting abuse.  Only
contractual controls prevent misuse in this scenario, whereas we have
well-understood technologies that allow technical measures to prevent misuse
that are preferred.

It's also still unclear to me that there's sufficient need to document the
symmetric key *redistribution* case in this document at all, if the only use
case is for "legacy feature parity".  Given that it's a fairly simple idea,
what is to stop us from leaving it undocumented in this Proposed Standard
and letting any implementors that need it do so on their own, or with a
separate Informational document mentioning its existence?  I am not aware of
any preexisting IETF work that we need to retain compatibility with, and the
data presented so far does not make a compelling (to me) case that we must
include this functionality in order for the IETF offering to be competitive.
(To be clear, I do not object to describing the use of symmetric keys for a
single-hop scenario, as the risks there are much smaller.)

I'd also like to have some additional discussion on this point from my
previous Discuss position, reproduced with typo fixed:
===
The combined defaults for the CDNI Metadata Interface for URI Signing seem
to be an unsafe combination.  Specifically, the default behavior for the
"issuers" property is to allow any Issuer, and the default for the
"jwt-header" property is to take the header from the JWT in band.  As far as
I can tell, this means that the dCDN will just blindly accept anything that
is formatted as a JWT and signed by any key known to the dCDN.  The
authentication and authorization properties of such behavior are so poor so
as to effectively be useless, absent some level of care surrounding key
management to isolate keys to given URIs.  In fact, the lack of substantive
discussion of key management and requirements thereof seems Discuss-worthy
in its own right.  We need to say something about obtaining a key along with
a trust path to what it's authorized to be used for, even if the specific
protocol mechanism for doing so is left out of scope.
===
I do see that §1.3 gained a mention of "obtain the key in a manner that
allows trust to be placed in the assertions made using that key", apparently
per my suggestion in my original COMMENT section.  However, I don't think
this is sufficient.  I strongly encourage a dedicated section on the
requirements for key management and how updates (both additions and
removals) of the list of trusted Issuer/key pairs are managed.  Failing
that, at a minimum the default for the "issuers" property in the CDNI
Metadata Interface needs to be changed to say that an empty list means that
any Issuer in the dCDN's trusted key store of issuers is acceptable for
signing JWTs for URI signing.  This is to be contrasted with "any Issuer at
all", which does not impose an obligation on the dCDN to maintain a list of
Issuer/key pairs trusted for signing JWTs used in signed URIs.

[Ballot comment]
Thanks for the updates to make use of "cdniip" NOT RECOMMENDED.  I'm still
uncomfortable about the way in which it is framed, but we have added enough
discussion of the risks it entails to make me demote it from being a
Discuss-level concern.

I'm also still uncomfortable about the directive to retain the same "jti"
value when re-signing in the redirection case, but in light of the input
from the IANA Designated Expert on the scope of potential harm from this
violation of RFC 7519, I have demoted that point from Discuss-level.

Thanks as well for adding the reference to RFC 8725, the JWT BCP.
I call attention to §3.11 thereof that recommends using explicit typing for
JWTs.  In the absence of evidence to the contrary, I believe that all new
JWT usage should include explicit type information; is there some reason why
explicit typing is not suitable here?

Thank you for acting on so many of my previous comments!  I think the
document is improved as a result.  I do retain some of my previous comments
that I didn't see any response to or changes as a result of, and have some
new comments interspersed as well.

Section 1.2

  before redirecting a UA to the CDN.  Using these attributes, it is
  possible for a CDN to check an incoming content request to see
  whether it was authorized by the CSP (e.g., based on the UA's IP
  address or a time window).  To prevent the UA from altering the

In light of cdniip being NOT RECOMMENDED, should the "UA's IP address" still
be mentioned in this parenthetical?

  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
  [...]
  JWT.  If applicable, the CDN checks whether the source IP address of
  the HTTP request matches the one in the Signed URI and/or if the time
  window is still valid.  [...]

Similarly, even if we may feel a need to include IP address in the
description here for completeness, we might want to shift the focus by
mentioning the more-recommended option first.

Section 2

  o  URI Signing Package (URISigningPackage): The URI attribute that
      encapsulates all the URI Signing claims in a signed JWT encoded
      format.  This attribute is exposed in the Signed URI as a path-
      style parameter or a form-style parameter.

Is there a good reference for "URI attribute"?  It sounds like should be
a technical term but I couldn't find a clear definition.

  The URI Signing Package will be found by parsing any path-style
  parameters and form-style parameters looking for a key name matching
  the URI Signing Package Attribute.  Both parameter styles MUST be
  supported to allow flexibility of operation.  The first matching
  parameter SHOULD be taken to provide the signed JWT, though providing
  more than one matching key is undefined behavior.  Path-style
  parameters generated in the form indicated by Section 3.2.7 of
  [RFC6570] MUST be supported.  Form-style parameters generated in the
  form indicated by Sections 3.2.8 and 3.2.9 of [RFC6570] MUST be
  supported.

The last two sentences seem a bit redundant with the second sentence
("Both parameter styles MUST be supported..."); it would be advisable to at
least use a lowercase "must" in the earlier sentence to avoid stating the
same normative requirement twice, if not just remove the redundant content
entirely.

Section 2.1

  The following claims (where the "JSON Web Token Claims" registry
  claim name is specified in parenthesis below) are used to enforce the
  distribution policies.  All of the listed claims are mandatory to
  implement in a URI Signing implementation, but are not mandatory to
  use in a given signed JWT.  (The "optional" and "mandatory"
  identifiers in square brackets refer to whether or not a given claim
  MUST be present in a URI Signing JWT.)

The final parenthetical suggests that the previous sentence should read
"not necessarily mandatory to use" (since apparently some of them *are*
mandatory to use).  Though I do see this was noted by Roman as well.  I
would be interested to hear why cdniuc is not mandatory (see below)...

  Note: The time on the entities that generate and verify the signed
  URI MUST be in sync.  In the CDNI case, this means that CSP, uCDN,
  and dCDN servers need to be time-synchronized.  It is RECOMMENDED to
  use NTP [RFC5905] for time synchronization.

I note that RFC 8915 presents Network Time Security for NTP, which might be
a helpful reference (and, arguably, worth recommending in its own right).
RFC 8633 is BCP 223, "Network Time Protocol Best Current Practices", also
worth referencing.

Section 2.1.x

[retained from my previous ballot position for posterity]
In general, my stance is that it's redundant to say that "the semantics
in Section X of RFC 7519 MUST be followed", because that's inherent in
the definition of the JWT claim.  But you're free to write the text as
you wish.

Section 2.1.1

  Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1
  MUST be followed.  If this claim is used, it MUST be used to confirm
  that the indicated key was provided by said issuer and used to sign
  the JWT.  [...]

I'm really confused at how these words fit together.  Is "the indicated key"
supposed to be a single unique key associated with the Issuer as identified
by the "iss" claim?  This is in general not true, as a given Issuer can have
more than one key in use.  Furthermore, what does it mean for the key to
have been "provided by" said issuer?  Provided when, as part of what
protocol flow?  If I ignore this sentence and just try to write something
based on my knowledge of JWT and expectations for how the CDNI URI Signing
works, I would write "If this claim is used, it MUST 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
keys used to sign JWTs, and must verify that the JWT was signed by one of
those keys."

            If the CDN verifying the signed JWT does not support Issuer
  verification, or if the Issuer in the signed JWT does not match the
  list of known acceptable Issuers, the CDN MUST reject the request.

I think this is intended to be "If this claim is used and the CDN verifying
the signed JWT [...]".

Also, I think this list also needs to include "if the Issuer claim does not
match the key used to sign the JWT".

Section 2.1.2

  Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2
  MUST be followed.  If this claim is used, it MUST be a JSON Web
  Encryption (JWE [RFC7516]) Object in compact serialization form,
  because it contains personally identifiable information.  This claim

While I am happy to see that the subject information is recognized as
PII and required to be protected, it seems that this formulation is
over-constrained.  Why does the Subject specifically need to be
compact-serialization-form JWE, as opposed to some other encrypted form
(that cannot be correlated to other instances of the same encrypted
Subject?  Why does just using a signed-and-encrypted JWT for the
containing JWT not suffice?

  contains information about the subject (for example, a user or an
  agent) that MAY be used to verify the signed JWT.  If the received
  signed JWT contains a Subject claim, then any JWT subsequently
  generated for CDNI redirection MUST also contain a Subject claim, and
  the Subject value MUST be the same as in the received signed JWT.  [...]

Strict value equivalence seems problematic (given that we mandate
compact-form JWE), since there is a key (re)distribution problem for
making the information usable to any dCDN that is involved.  If it's
encrypted using a symmetric key, then the uCDN sharing it to the dCDN
introduces the same issue as for "signed" JWTs -- the dCDN can
impersonate the CSP; if it's using an asymmetric key then the set of
recipients is fixed at JWE creation (by the CSP) and we either lose the
ability to seamlessly add CDN tiers or have to redistribute the private
key (which is against best practices), in order to meet the "byte for
byte the same value" requirement.  What motivates the prohibition of
re-encrypting for the next level of hierarchy?  I think that in the JWT
convention we could say that the "the Subject identified by the value of the
'sub' claim in any JWT subsequently generated for CDNI redirection MUST be
the same as the Subject identified by the value of the 'sub' claim in the
received signed JWT" to achieve a requirement that the information content
remain unchanged, without requiring strict value equivalence.

Section 2.1.3

  Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3
  MUST be followed.  This claim is used to ensure that the CDN
  verifying the JWT is an intended recipient of the request.  The claim
  MUST contain an identity on behalf of whom the CDN can verify the
  token (e.g., the CSP or any CDN in the chain).  A CDN MAY modify the
  claim as long it can generate a valid signature.

While a setup that naively translates JWT semantics to the CDNI case would
have the CSP issue a JWT with Audience of the uCDN (or some meta-Audience
for the combination of uCDN and dCDN), and then either the uCDN would
re-sign with the dCDN as the Audience or the dCDN would be configured to
recognize the Audience used by the CSP as being valid for itself, I think I
see what is intended here, that the CSP issues a JWT with Audience that
corresponds to the request as targeted to the CSP and ultimately ending up
at one or more CDNs.  That is, the CDNs know what CSP a given request is
supposed to come from, and can match the audience value against the CSP's
identification or an upstream CDN in addition to its own identification.  In
that case, I would suggest rewording to something like "The claim MUST
contain an identity belonging to the chain of entities involved in
processing the request (e.g., identifying the CSP or any CDN in the chain)
that the recipient is configured to use for the processing of this request".

Section 2.1.7

I think we need to make some statement (not necessarily here) about whether
the JWT ID used in JWTs issued by token renewal use the same or different
JWT IDs.  Currently we don't seem to say anything, and that seems likely to
lead to interoperability issues.

Section 2.1.9

It might be worth asking the OAuth WG if there's seen to be value in
having a generic "crit" claim that protocols can require comprehension
of, to hold a list of claims that are critical for that token in that
protocol.

Section 2.1.10

[same comments about encryption as for Subject]

Section 2.1.12

Can we give any guidance on what kind of values might make sense for the
CDNI Expiration Time Setting field and still providing some reasonable
security properties?  (Conversely, what kind of values are so large so
as to be nonsensical?)

Section 2.1.14

The first two paragraphs seem to talk about this claim as being a
direction to the client of when to send such a token along with a
request, but the third paragraph seems to talk about it as being a
direction to the CDN for generating new tokens as part of Signed Token
Renewal.  This leaves me confused about what the intended usage actually
is.

Section 2.1.15

  The URI Container (cdniuc) claim takes one of the following forms:
  'hash:' or 'regex:'.  More forms may be added in the future to extend
  the capabilities.

How will a JWT producer know whether a JWT consumer knows about any such
extended functionality?

Section 2.1.15.2

  An example of a 'regex:' is the following:

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

It seems a bit surprising to just do a wildcard match on scheme and
assume that the path components will be meaningful for that scheme.
Perhaps a variation that used branches to match only http or https
schemes would be preferred?

Section 4.4

      Property: issuers

        Description: A list of valid Issuers against which the Issuer
        claim in the signed JWT may be cross-referenced.

Cross-referencing or verifying against the JWT issuer is only part of
verifying a JWT; there needs to also be a binding between Issuer and key(s)
used to sign JWTs.  I think we should say something here about how the
Issuer/key binding is tracked, since it is apparently not part of the CDNI
metadata interface.

      Property: jwt-header

        Description: The header part of JWT that is used for verifying
        a signed JWT when the JWT token in the URI Signing Package does
        not contain a header part.

To me, "the header part of [a] JWT" would mean the base64-encoded version.
The example below uses a native JSON object.  I strongly suggest being more
precise about what this property is supposed to contain.  (Also,
RFC 8519 does not use the phrase "JWT header", and refers only to the "JOSE
header".)

  The following is an example of a URI Signing metadata payload with
  explicit values:

  {
    "generic-metadata-type": "MI.UriSigning"
    "generic-metadata-value":
      {
        "enforce": true,
        "issuers": ["csp", "ucdn1", "ucdn2"],

It might be more helpful to use the URI form of the Issuer names, since
in this generic RFC we do not have any deployment-specific context that
would allow the use of a short string issuer identifier.

Section 5.2

  2.  CSP provides to the uCDN the information needed to verify Signed
        JWTs from that CSP.  For example, this information will include
        one or more keys used for validation.

  3.  Using the CDNI Metadata interface, the uCDN communicates to a
        dCDN the information needed to verify Signed JWTs from the CSP
        [...]

Thanks for making changes so that the phrasing in this section more closely
matches the phrasing of the previous section!  It looks like the previous
section switched from "Signed JWTs" here to "signed URIs", so we might need
to catch up (twice).

Appendix A.3

  Once the server verifies the signed JWT it will return a new signed
  JWT with an updated expiry time (exp) as shown below.  Note the
  expiry time is increased by the expiration time setting (cdniets)
  value.

My previous comment was:
===
This example is adding the "cdniets" value to the previous "exp" value,
but the specification for this claim says that it is added to the "time
at which the JWT is verified", which is unlikely to be exactly the
previous "exp" value.  I suggest adding a few words about this and using
a different (earlier) "exp" in the re-signing example.
===
It looks like the update to use more-current "exp" values has caused the
"add the 'cdniets' value" step to be skipped, so that the two "exp" values
are identical.  I don't think they can actually be identical with "cdniets"
set to 30.

NITS

Section 1.2

  address or a time window).  To prevent the UA from altering the
  claims a JWT MUST be signed.

I think "the JWT" would flow better here.

Section 1.3

  routing.  Note that the signed Redirection URI MUST maintain HTTPS as
  the scheme if it was present in the original and it MAY be upgraded
  from HTTP to HTTPS.

When referring to URI schemes, we typically use the lower-case for "http:"
and "https:".

Section 2.1.9

  Its value is a comma separated listing of claims in the Signed JWT
  that use those extensions.  If any of the listed extension claims are

The causality seems reversed -- isn't it that the extensions use the claims
being marked critical, rather than the claims using the extensions?  So,
s/that use/that are used by/?

Section 2.1.15

      all other purposes will use the original URI.  If the signed JWT
      is terminated by anything other than a sub-delimiter (as defined
      in [RFC3986] Section 2.2), everything from the reserved character
      (as defined in [RFC3986] Section 2.2) that precedes the URI
      Signing Package Attribute to the last character of the signed JWT
      will be removed, inclusive.  Otherwise, everything from the first

Do we mean "immediately preceeds" here?

  *  Normalize the URI according to section 2.7.3 [RFC7230] and
      sections 6.2.2 and 6.2.3 [RFC3986].  This applies to both
      generation and verification of the signed JWT.

The HTTP spec is being revised, so Section 4.2.3 of
draft-ietf-httpbis-semantics may be a better reference than RFC 7230 here.

[Ballot comment]
Thanks for addressing by DISCUSS and COMMENT feedback on the original ballot on -21.

Also, thanks to Brian Campbell and other OAuth WG members for the discussion on the reuse of the same jti claim value when signing different JWT content (i.e., what constitutes “different data object(s)”) across multiple CDNs.

[Ballot comment]
Thank you for fixing all my previous COMMENTs in the -22 revision and addressing parts of my previous DISCUSS by using “NOT RECOMMENDED” in section 2.1.10 in the -24 revision.

I am afraid that I still do not see the value of having cdniip in this document, but, as I do not want to block this document, I am balloting ABSTAIN.

The section 7 (security considerations) is still very light on the IP address sharing. I would welcome some applicability statements on the use of cdniip.

-éric

== DISCUSS (kept for archive) ==

-- Section 2.1.10 --
About "Client IP (cdniip) claim", I really wonder whether this could be used in real life as some IPv4 Carrier-Grade NAT (CGN) have a large pool of "public" IPv4 addresses that could select different public IPv4 addresses if badly designed. How will it work with dual-stack UAs where some connections could be over IPv4 and some over IPv6 ? Now to mention a dual-home (Wi-Fi & mobile data) UA ? Or what if the dCDN is between the UA and the CGN (assuming that the uCDN or CSP are upstream of the CGN) ?

Also, "If the received signed JWT contains a Client IP claim" uses singular rather than "one or several"

I also noted that Section 7 (security considerations) puts some restrictions on the usefulness of cdniip.

I would welcome some applicability statements on the use of cdniip.

[Ballot comment]
Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ppG3onLlgjXu_hULqu3LVQPq0iY).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1.2. , paragraph 3, nit:
> e way in the initial steps #1 and #2 but the later steps involve multiple CD
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 2. , paragraph 2, nit:
> gistry claim name is specified in parenthesis below) are used to enforce the
>                                ^^^^^^^^^^^^^^
Did you mean "in parentheses"? "parenthesis" is the singular.

Section 2.1. , paragraph 6, nit:
>  If the received signed JWT contains a Expiry Time claim, then any JWT subse
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.1.7. , paragraph 2, nit:
> rejected if sourced from a client outside of the specified IP range. Since th
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 2.1.8. , paragraph 2, nit:
> , and mobile clients switching from WiFi to Cellular networks where the clie
>                                    ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 2.1.15. , paragraph 4, nit:
> ed URIs would require to be valid for a at least 30 minutes, thereby reducing
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.1.15.2. , paragraph 6, nit:
> s generated, the model is not broken and the User Agent can successfully ret
>                                    ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 3.3. , paragraph 2, nit:
> orm verification, regardless of whether or not the URI is signed. Type: Bool
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

These URLs in the document can probably be converted to HTTPS:
* http://www.iso.org/standard/65274.html
* http://www.iana.org/assignments/jwt
* http://pubs.opengroup.org/onlinepubs/9699919799/

[Ballot discuss]
Thank you for the work put into this document.

Thank you for fixing all my previous COMMENTs in the -22 revision.

I am afraid that I need to keep my DISCUSS about the cdniip even with the addition of a paragraph at the end of section 2.1.10... This paragraph ressembles to an application statement but it it really light. Why did the authors select not to use RFC 8174 normative language “NOT RECOMMENDED” ?

The section 7 (security considerations) is still very light on the IP address sharing.

-éric

== DISCUSS ==

-- Section 2.1.10 --
About "Client IP (cdniip) claim", I really wonder whether this could be used in real life as some IPv4 Carrier-Grade NAT (CGN) have a large pool of "public" IPv4 addresses that could select different public IPv4 addresses if badly designed. How will it work with dual-stack UAs where some connections could be over IPv4 and some over IPv6 ? Now to mention a dual-home (Wi-Fi & mobile data) UA ? Or what if the dCDN is between the UA and the CGN (assuming that the uCDN or CSP are upstream of the CGN) ?

Also, "If the received signed JWT contains a Client IP claim" uses singular rather than "one or several"

I also noted that Section 7 (security considerations) puts some restrictions on the usefulness of cdniip.

I would welcome some applicability statements on the use of cdniip.

[Ballot comment]
Thank you for the work on this document.

One more comment to add to those of my fellow ADs: please align the claim description and the section name for the Client IP (cdniip) claim (description in IANA section 6.6.1 is "CDNI IP Address").

Francesca

[Ballot comment]
The IANA Considerations section creates two registries under Specification Required rules.  RFC 8126 recommends that the defining document include advice to the designated experts (thank you for volunteering, by the way) about how to evaluate new submissions, but none are included here.  Are any appropriate?

This seems to be my pet peeve this week, but I'm wondering about most of the SHOULDs in this document.  Why aren't they MUSTs?  Or in the alternative, could we include some guidance about when an implementer might legitimately choose to deviate from what the SHOULD says to do?

I support Roman's DISCUSS position about Section 1.3.

[Ballot discuss]
I support Éric's and Erik's and Roman's Discusses.

We've had similar issues with embedding client IP addresses in security
tokens all over the place, e.g., in Kerberos tickets, where it provided
negligible security benefit and frequently caused (hard to diagnose!)
breakage.
I further note based on some of the responses so far that (as I
understand it) the issues of multiple client IPs is quite realistic just
for making requests to the CSP vs the uCDN, and no amount of
time-locality can save us.
I expect that the IESG will have some in-person discussion of this topic
and what we are willing to put in an IETF-stream RFC.  (My own personal
opinion is that we have a fair amount of leeway to document "some people
are doing this thing" accompanied by explanations of the flaws in that
practice, but that we have very limited scope to recommend bad
practices.)

I think we should also discuss the proposed technique of redistributing
shared secrets used to generate MACs for signed JWTs.  I see a minimal
acknowledgment that there is potential cause concern in the penultimate
paragraph of the security considerations that "it is important to know
the implications of a compromised shared key", but in my mind the text
there does not really call out the severity of those implications.  I
would have expected something like "redistributing the shared key in
this manner allows the dCDNs to impersonate the CSP to the uCDN and
produce arbitrary signed URLs that are accepted by the uCDN as
authentic".  Well, what I *actually* would have expected was to just not
define this mechanism at all, as it is too risky to use a group-shared
symmetric key in a group where participants are at different trust
levels.  But perhaps the WG can produce some explanation of why this is
acceptable...

I also have concerns about our guidance to leave the JWT "jti" unchanged
when re-signing with different contents, e.g., changing Issuer and/or
Audience, etc..  We don't seem to mention one way or another whether
"jti" needs to be preserved while performing Signed Token Renewal, but
changing the "exp" while preserving "jti" seems like it would be
problematic as well.  The guidance in RFC 7519 is somewhat vague
(basically, that it needs to change if it identifies a "different data
object"), so we may want to consult the broader OAuth WG (not
necessarily just the IANA DE) for further interpretation.  I can also
add based on the responses so far that the "jti" is not solely to be
used to prevent replay, and so I am skeptical of reasoning based on such
an argument.

The combined defaults for the CDNI Metadata Interface for URI Signing
seem to be an unsafe combination.  Specifically, the default behavior
for the "issuers" property is to allow any Issuer, and the default for
the "jwt-header" property is to take the header from the JWT in band.
As far as I can tell, this means that the dCDN will just blindly accept
anything that is formatted as a JWT and signed by any key nown to the
dCDN.  The authentication and authorization properties of such behavior
are so poor so as to effectively be useless, absent some level of care
surrounding key management to isolate keys to given URIs.  In fact, the
lack of substantive discussion of key
management and requirements thereof seems Discuss-worthy in its own
right.  We need to say something about obtaining a key along with a
trust path to what it's authorized to be used for, even if the specific
protocol mechanism for doing so is left out of scope.

[Ballot comment]
Balloting late in the week I have the benefit of seeing the comments of
the other ADs.  I've tried to suppress duplicates but no doubt have
missed a few; sorry for the extra work and feel free to just reference
some other discussions instead of repeating their contents.

Please don't refer to the "jti" claim as a "Nonce".  There is a separate
registered "nonce" JWT claim that plays a different role, and mixing up
the terminology is confusing, even if the JWT ID value can be used as a
nonce in some circumstances (but not all).

Please reference (and act on, if/as appropriate) the JWT BCP (RFC 8725).

Section 1

  Specifically, the CDNI Framework [RFC7336] states:

      The CSP may also trust the CDN operator to perform actions such as
      delegating traffic to additional downstream CDNs, and to enforce
      per-request authorization performed by the CSP using techniques
      such as URI Signing.

  In particular, the following requirement is listed in the CDNI
  Requirements [RFC7337]:

(editorial) It reads a bit oddly to have both a "specifically" and an
"in particular"; the second line might be reframed as more of an
"additionally" or "also" type remark.

Section 1.2

  A CSP and CDN are assumed to have a trust relationship that enables
  the CSP to authorize access to a content item by including a set of
  claims in the form of a signed JWT in the URI before redirecting a UA
  to the CDN.  [...]

nit/editorial: the trust relationship is what enables the authorization
of access, but using claims in a signed JWT to effectuate that is more
of an implementation agreement that builds on the trust relationship
than an aspect of the trust relationship itself.  So this could be
"enables the CSP to authorize access to a content item, which is
realized in practice by including a set of claims in a signed JWT", or
similar.

Section 1.3

                      In step #3, the UA may send an HTTP request or a
  DNS request.  Depending on whether HTTP-based or DNS-based request
  routing is used.  [...]

nit: sentence fragment.

                                        Regardless of the type of keys
  used, the verifying entity has to obtain the key (either the public
  or the symmetric key).  [...]

Not just obtain the key, but obtain it in a manner that allows trust to
be placed in the assertions made using that key.

Section 2

  o  URI Signing Package (URISigningPackage): The URI attribute that
      encapsulates all the URI Signing claims in a signed JWT encoded
      format.  This attribute is exposed in the Signed URI as a path-
      style parameter or a form-style parameter.

Is there a good reference for "URI attribute"?  It sounds like should be
a technical term but I couldn't find a clear definition.

  The URI Signing Package will be found by parsing any path-style
  parameters and form-style parameters looking for a key name matching
  the URI Signing Package Attribute.  Both parameter styles MUST be
  supported to allow flexibility of operation.  The first matching
  parameter SHOULD be taken to provide the signed JWT, though providing
  more than one matching key is undefined behavior.

Shouldn't the metadata specify which parameter style is going to be
used?  (Perhaps two, rather than one, new values for cdnistt?)

Section 2.1

  The following claims (where the "JSON Web Token Claims" registry
  claim name is specified in parenthesis below) are used to enforce the
  distribution policies.  All of the listed claims are mandatory to
  implement in a URI Signing implementation, but are not mandatory to
  use in a given signed JWT.  (The "optional" and "mandatory"
  identifiers in square brackets refer to whether or not a given claim
  MUST be present in a URI Signing JWT.)

The final parenthetical suggests that the previous sentence should read
"not necessarily mandatory to use" (since apparently some of them *are*
mandatory to use).  Though I do see this was noted by Roman as well.  I
would be interested to hear why cdniuc is not mandatory (see below)...

  Note: The time on the entities that generate and verify the signed
  URI SHOULD be in sync.  In the CDNI case, this means that CSP, uCDN,
  and dCDN servers need to be time-synchronized.  It is RECOMMENDED to
  use NTP [RFC5905] for time synchronization.

It's surprising that this is only a SHOULD-level requirement for time
synchronization, given the scope of issues that can result if time is
not synchronized.  When would it be okay to ignore the SHOULD?

Also, separately, I note that RFC 8915 presents Network Time Security
for NTP, which might be a helpful reference (and, arguably, worth
recommending in its own right).

Section 2.1.x

In general, my stance is that it's redundant to say that "the semantics
in Section X of RFC 7519 MUST be followed", because that's inherent in
the definition of the JWT claim.  But you're free to write the text as
you wish.

Section 2.1.1

  Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1
  MUST be followed.  This claim MAY be used to verify authorization of
  the issuer of a signed JWT and also MAY be used to confirm that the
  indicated key was provided by said issuer.  If the CDN verifying the

What is meant by "to verify authorization of the issuer of a signed
JWT"?  In some sense, the "iss" claim is meaningless unless the JWT
signature is validated as having been generated by a trusted key
associated that belongs to the "iss" identity (or the JWT was received
on a trusted channel, which of course does not apply here since it's via
the UA).  (Also note that the JWT BCP (RFC 8725) has some things to say
about when to use "iss" and how that relates to whether a given key is
used in more than one context...)

  signed JWT does not support Issuer verification, or if the Issuer in

I think this is intended to be "If an Issuer claim is present and the
CDN verifying the signed JWT [...]".

  the signed JWT does not match the list of known acceptable Issuers,
  the CDN MUST reject the request.  [...]

I think this list also needs to include "if the Issuer claim does not
match the key used to sign the JWT".

Section 2.1.2

  Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2
  MUST be followed.  If this claim is used, it MUST be a JSON Web
  Encryption (JWE [RFC7516]) Object in compact serialization form,
  because it contains personally identifiable information.  This claim

While I am happy to see that the subject information is recognized as
PII and required to be protected, it seems that this formulation is
over-constrained.  Why does the Subject specifically need to be
compact-serialization-form JWE, as opposed to some other encrypted form
(that cannot be correlated to other instances of the same encrypted
Subject?  Why does just using a signed-and-encrypted JWT for the
containing JWT not suffice?

  contains information about the subject (for example, a user or an
  agent) that MAY be used to verify the signed JWT.  If the received
  signed JWT contains a Subject claim, then any JWT subsequently
  generated for CDNI redirection MUST also contain a Subject claim, and
  the Subject value MUST be the same as in the received signed JWT.  [...]

Strict value equivalence seems problematic (given that we mandate
compact-form JWE), since there is a key (re)distribution problem for
making the information usable to any dCDN that is involved.  If it's
encrypted using a symmetric key, then the uCDN sharing it to the dCDN
introduces the same issue as for "signed" JWTs -- the dCDN can
impersonate the CSP; if it's using an asymmetric key then the set of
recipients is fixed at JWE creation (by the CSP) and we either lose the
ability to seamlessly add CDN tiers or have to redistribute the private
key (which is against best practices), in order to meet the "byte for
byte the same value" requirement.  What motivates the prohibition of
re-encrypting for the next level of hierarchy?

Section 2.1.3

  Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3
  MUST be followed.  This claim is used to ensure that the CDN verifing
  the JWT is an intended recipient of the request.  The claim should
  contain an identity on behalf of whom the CDN can verify the token
  (e.g., the CSP or any uCDN in the chain).  A dCDN MAY modify the
  claim as long it can generate a valid signature.

While RFC 7519 does say that "[t]he processing of this claim is
generally application specific", the description here doesn't seem to
make a whole lot of sense.  It's supposed to be used by the entity
receiving the JWT, which is never going to be the CSP (which generates
the JWT).  My intuition is that typically the CSP would issue a JWT with
Audience of the uCDN (or some meta-Audience for the combination of uCDN
and dCDN), and then either the uCDN would re-sign with the dCDN as the
Audience or the dCDN would be configured to recognize the Audience used
by the CSP as being valid for itself.

Also, "the Audience used by the CSP" is perhaps ambiguous as to whether
that's the one inserted by the CSP or recognized by the CSP as being
itself.  So maybe "recognize the Audience inserted in the JWT by the
CSP"?

Section 2.1.4

  Expiry Time (exp) [optional] - The semantics in [RFC7519]
  Section 4.1.4 MUST be followed, though URI Signing implementations
  MUST NOT allow for any time synchronization "leeway".  If the CDN

Why do we have "MUST NOT allow for any [leeway]" when it's only
RECOMMENDED to have synchronized time?

  verifying the signed JWT does not support Expiry Time verification,

As above, I think this is meant to be "If the Expiry Time claim is
present and the CDN verifying [...]".

  or if the Expiry Time in the signed JWT corresponds to a time equal
  to or earlier than the time of the content request, the CDN MUST
  reject the request.  [...]

Section 2.1.5

[conceptually same comments as for §2.1.4, adjusted for the "nbf" claim]

Section 2.1.6

  Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6
  MUST be followed.  If the received signed JWT contains an Issued At
  claim, then any JWT subsequently generated for CDNI redirection MUST
  also contain an Issued At claim, and the Issuer value MUST be updated

nit: s/Issuer value/Issued At value/

Section 2.1.7

            If the signed JWT contains a Nonce claim and the CDN
  verifying the signed JWT either does not support Nonce storage or has
  previously seen the Nonce used in a request for the same content,
  then the CDN MUST reject the request.  [...]

As above, this seems predicated on the "jti" claim being present in a
received token.

Section 2.1.9

It might be worth asking the OAuth WG if there's seen to be value in
having a generic "crit" claim that protocols can require comprehension
of, to hold a list of claims that are critical for that token in that
protocol.

                              If any of the listed extension claims are
  not understood and supported by the recipient, then the Signed JWT is
  invalid.  [...]

(editorial) In the other sections we seem to use language about "MUST
reject the request" or "MUST reject the JWT" rather than just saying
that the JWT "is invalid"

Section 2.1.10

[same comments about encryption as for Subject]

Section 2.1.11

Why is the CDNI URI Container claim optional?  It seems like the URI
Signing cannot be fit for purpose if the URI being signed is not
contained in the token...

Section 2.1.12

Can we give any guidance on what kind of values might make sense for the
CDNI Expiration Time Setting field and still providing some reasonable
security properties?  (Conversely, what kind of values are so large so
as to be nonsensical?)

Section 2.1.14

The first two paragraphs seem to talk about this claim as being a
direction to the client of when to send such a token along with a
request, but the third paragraph seems to talk about it as being a
direction to the CDN for generating new tokens as part of Signed Token
Renewal.  This leaves me confused about what the intended usage actually
is.

Section 2.1.15

  The URI Container (cdniuc) claim takes one of the following forms:
  'hash:' or 'regex:'.  More forms may be added in the future to extend
  the capabilities.

How will a JWT producer know whether a JWT consumer knows about any such
extended functionality?

Section 2.1.15.2

  An example of a 'regex:' is the following:

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

It seems a bit surprising to just do a wildcard match on scheme and
assume that the path components will be meaningful for that scheme.
Perhaps a variation that used branches to match only http or https
schemes would be preferred?

Section 3.2

  this document.  However, in order to also support legacy UAs that do
  not include any specific provisions for the handling of signed JWTs,
  Section 3.3 defines a mechanism using HTTP Cookies [RFC6265] that
  allows such UAs to support the concept of renewing signed JWTs
  without requiring any additional UA support.

(editorial) the way this sentence is written suggests that the §3.3
cookie-based mechanism is distinct from the mechanism described here
(most notably due to the use of the word "also"), but it looks like the
mechanism described here also uses cookies.  Are the two actually
distinct?

Section 3.2.1

(editorial) typically we don't use second-person language ("you") in RFC
style.

Section 3.3.1

  In such scenarios, Signed Token Renewal of a signed JWT SHOULD be
  communicated via the query string instead, in a similar fashion to
  how regular signed JWTs (outside of Signed Token Renewal) are
  communicated.  Note that the use of URL embedded signed JWTs SHOULD
  NOT be used in HTTP 2xx Successful messages, since UAs might not know
  how to extract the signed JWTs.

I don't think I understand how (in the last sentence) a URL embedded
signed JWT would be used in an HTTP 2xx response, since the response
would just be normal application content and there's not a particularly
well-defined place to put a URL with embedded JWT.

Section 4

  necessary to allow the dCDN to verify a Signed URI.  Events that
  pertain to URI Signing (e.g., request denial or delivery after access
  authorization) need to be included in the logs communicated through
  the CDNI Logging interface.

(editorial) I don't think I understand what is meant by "e.g., request
denial or delivery after access authorization".  I'm not even 100% sure
if I'm supposed to group thing as "(request denial or delivery) (after
access authorization)" or "(request denial) or (delivery after access
authorization)".  My initial thought was the latter, but "delivery after
access authorization" really doesn't make much sense to me; my current
thinking is that it's the former and that s/after access
authorization/after an access authorization decision has been made/
would clarify.

Section 4.4

      Property: issuers

        Description: A list of valid Issuers against which the Issuer
        claim in the signed JWT may be verified.

Issuers should always be tied to keys that they control.  Leaving keys
and issuer identities to be managed separately invites identity
misbinding attacks.

      Property: package-attribute

        Description: The name to use for the URI Signing Package.

(nit?) Should this be "The attribute name to use"?

      Property: jwt-header

        Description: The header part of JWT that is used for generating
        or verifying a signed JWT when the JWT token in the URI Signing
        Package does not contain a header part.

(editorial) IIUC this metadata interface is for the uCDN to provide
information to the dCDN that the dCDN will use for processing requests
(i.e., in this case, for verifying JWTs).  In that context, I don't see
how it's useful to say that this is the header part of the JWT "that is
used for generating", since the dCDN only needs to verify these JWTs.
If the dCDN is issuing its own JWTs when acting as an uCDN in a
hierarchy, it can list its own jwt-header in its own published metadata.

  The following is an example of a URI Signing metadata payload with
  explicit values:

  {
    "generic-metadata-type": "MI.UriSigning"
    "generic-metadata-value":
      {
        "enforce": true,
        "issuers": ["csp", "ucdn1", "ucdn2"],

It might be more helpful to use the URI form of the Issuer names, since
in this generic RFC we do not have any deployment-specific context that
would allow the use of a short string issuer identifier.

Section 5

  URI Signing supports both HTTP-based and DNS-based request routing.
  JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of
  representing claims to be transferred between two parties.  The
  claims in a signed JWT are encoded as a JSON object that is used as
  the payload of a JSON Web Signature (JWS) structure or as the
  plaintext of a JSON Web Encryption (JWE) structure, enabling the
  claims to be digitally signed or integrity protected with a Message
  Authentication Code (MAC) and/or encrypted.

AFAICT this is the only place in the document where we refer to a
possibility of using JWE over the entire JWT (as opposed to just the
Subject or IP address claim bodies).  Yes, this is in some sense a
generic statement about JWT and not necessarily attempting to apply to
the URI Signing usage of JWT, but it still seems out of place.  I would
have expected that we just stick to talking about JWS (or, I suppose,
that JWE was mentioned consistently throughout, but it doesn't seem to
be a great fit for this application anyway).

Section 5.1

  2.  CSP provides to the uCDN the information needed to verify signed
        JWTs from that CSP.  For example, this information may include a
        key value.

When would it not include a key value?

  3.  Using the CDNI Metadata interface, the uCDN communicates to a
        dCDN the information needed to verify signed JWTs 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.

It would also include key material if the uCDN is re-signing, right?
So either we should mention key material here or change (9) to not
mention "computes".

  4.  When a UA requests a piece of protected content from the CSP,
        the CSP makes a specific authorization decision for this unique
        request based on its personal distribution policy.

(nit) I'd suggest s/personal/local/, since the CSP is typically not a
person.

Section 5.2

  2.  CSP provides to the uCDN the information needed to verify
        cryptographic signatures from that CSP.  For example, this
        information may include a key.

As above, when would this not include a key value?

  4.  When a UA requests a piece of protected content from the CSP,
        the CSP makes a specific authorization decision for this unique
        request based on its arbitrary distribution policy.

We should use a consistent term between the previous section and here (I
still prefer "local" but the actual word doesn't matter very much).
In general, I'd recomment harmonizing the phrasing between the two
sections; there are several differences that appear when I run a diff,
including "Signed URI" vs "cryptographic signature" or "signed JWTs" vs
"cryptographic signatures".

  12.  If the verification is negative, the dCDN rejects the request
        and sends an error code 403 Forbidden in the HTTP response.

  13.  If the verification is positive, the dCDN serves the request and
        delivers the content.

(nit) I'd suggest "verification result" both here and above.

Section 6.4

  is a 3DIGIT value as defined in Section 4.5.  Additions to the CDNI
  URI Signing Verification Code namespace will conform to the
  "Specification Required" policy as defined in [RFC8126].  Updates to
  this subregistry are expected to be sparse.

(nit) one might interpret "sparse" either as meaning a long time between
allocations or that the numerical values assigned will not be contiguous
ranges, which might be worth clarifying.
(This holds for both the new registries, I think.)

  | 406  | RFCthis  | Signed JWT verification performed and        |
  |      |          | rejected because of Issued At enforcement    |

It's not clear to me what kind of Issued At enforcement might lead to
rejection -- there is no mention of rejection made in §2.1.6, for
example.


Should there be a code for "only one of cdnistt and cdniets present"?

Section 7

                              Whenever the dCDN receives a request with
      a given unique ID, it adds that ID to the list of 'used' IDs.  In
      the case an illegitimate UA tries to use the same URI through a
      replay attack, the dCDN can deny the request based on the already-
      used access ID.

You probably also want to mention expiring out IDs from the list of
'used' IDs when they expire, or this becomes an unbounded state-keeping
requirement...

Section 8

The main body text mentioned both Subject and IP address as having
potential privacy concerns; why do we only mention IP address here?

Section 11.2

https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
suggests that with NTP being RECOMMENDED, RFC 5905 would be classified
as normative.

Appendix A

The "exp" times are in 2016; if regenerating the examples is automated
using newer dates might be nice (but the risk of getting into an
inconsistent state if redoing them by hand is too big to merit changing
the dates in that case, IMO).

Appendix A.3

  Once the server verifies the signed JWT it will return a new signed
  JWT with an updated expiry time (exp) as shown below.  Note the
  expiry time is increased by the expiration time setting (cdniets)
  value.

This example is adding the "cdniets" value to the previous "exp" value,
but the specification for this claim says that it is added to the "time
at which the JWT is verified", which is unlikely to be exactly the
previous "exp" value.  I suggest adding a few words about this and using
a different (earlier) "exp" in the re-signing example.

[Ballot discuss]
Apologies for piling on, but I want to second Eric Vyncke's Discuss.  The
use of Client IP addresses is more problematic than one might suspect from
a reading of this document.

RFC 8305 Happy Eyeballs means for a dualstack client and a dualstack CSP or
CDN there are no guarantees that the address family will be the same.

Furthermore, a client using RFC 8981 (4941bis) IPv6 temporary addresses might
change source address (even with every request) so an exact match would not be
recommended.

To make matters even more complicated, a mobile client might make the CSP
request on Wi-Fi, walk out of range, and complete a subsequent CDN request
via its mobile provider network (or vice versa).  So, even using a fairly
short CIDR length for truncation may not work since the origin network can be
completely different between requests.

The latter behaviour can also be trigger by connection migration transports,
like MPTCP and (soon) QUIC.

I think one solution might include relaxing all the MUSTs in section 2.1.10.
Instead, perhaps some text that clarifies the presence of reliability issues
with Client IPs and recommends that CDNs be develop a more sophisticated
policy (or avoid using this altogether and prefer to use other claims).
Including the Client IP for logging purposes might be helpful, but being too
strict about verifying it can lead to client-visible failures.

Alternatively, UAs need to be augmented to know that when a cdniip is part
of the claim that it must try to keep the source IP address the same for
subsequent requests, recognizing, as section 7 does, that NAT can make this
impossible.  I'm not sure this is a workable option, though.

[Ballot discuss]
** Section 1.3.  Per “Note that the signed Redirection URI MUST maintain the same (or higher) level of security as the original Signed URI.”:

-- How is this equivalence assessed?

-- Can one create an architecture to that cascades a mix of uCDNs whose path will mix both asymmetric and symmetric keys?  Assuming that’s possible what’s “same or higher” here?

** Section 2.1.7.  The specified use of the jti claim in the URI signing workflow appears to conflict with the underlying definition of this claim in RFC7519.

(a) Section 1.3. says “… the CSP needs to allow the uCDN to redistribute shared keys to a subset of their dCDNs.”

(b) Section 2.1.7 says “If the received signed JWT contains a Nonce claim, then any JWT subsequently generated for CDNI redirection MUST also contain a Nonce claim, and the Nonce value MUST be the same as in the received signed JWT.”

(c.1) Section 4.1.7 of RFC7519 says “The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object …

(c.2) Section 4.1.7 of RFC7519 also says “… if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well.”

The constraints in (b) suggests that the Nonce claim value needs to be the same across every logical hop in the cascading CDN path.  My understanding of the architecture is that some of the claims in the JWTs such as the cdniuc or cdnistd claims might changes when there are cascading CDNs.  If they change, this seems like that would constitute a different “data object” who have the same unique (jti claim) identifier which would violate (c.1).  One could argue that perhaps the CDNs are at arm-length so they aren’t really an “application us[ing] multiple issuers”, however, the architectural construct of shared keys suggested by (a) seems to imply otherwise which would suggest that this violated (c.2).  If I’ve misunderstood the architecture let me know.

The notion of keeping the nonce the same seems like the right design, its just the reuse of this particular claim seems mismatched.

[Ballot comment]
I support Éric Vyncke DISCUSS position.

** Section 2.1.  Per “(The "optional" and "mandatory" identifiers in square brackets refer to whether or not a given claim MUST be present in a URI Signing JWT.)”, this guidance is clear, but I don’t see any “[mandatory]” claims.

** Section 2.3.  Is there any specific guidance on how to construct this identity in an interoperable way for CDNI?  In OAuth, the answer was largely no.

** Section 2.1.7.  Given the CDNI use case and expected lifetime of the JWTs, are there any recommendations on nonce size?

** Section 2.2.  Per “The header value must be transmitted …”, should this be a normative MUST?

** Section 3.3.1.  Per the text around supporting cross-domain redirection of signed token renewal, the guidance is that “[i]n such scenarios, Signed Token Renewal of a signed JWT SHOULD be communicated via the query string instead …” and not via the 'URISigningPackage' cookie as specified in Section 3.3.  Since Section 3.2.1 noted that cdnistt MUST be included, what value should be set for a JWT passed in the query string?

** Section 5.2.  Per “This raises a security concern for applicability of URI Signing with symmetric keys in case of DNS-based inter-CDN request routing”, this caution seems appropriate.  Is there is a reason that stronger normative language such as “this architecture is NOT RECOMMENDED” is not used?  It seems like this should also be reiterated in the security considerations sections.

** Section 7.  Per “One way to reduce exposure to this kind of attack is to not only check for Client IP but also for other attributes, e.g., attributes that can be found in HTTP headers”, can you say more on how this fingerprinting should be operationalized?  Knowing the application in question, couldn’t the  illegitimate clients also reproduce these headers?

** Nits
-- Section 2.1.3.  Typo. s/verifing/verifying/

-- Section 2.1.15.  Typo. s/definined/defined/

-- Section 3.2.1. Editorial.  The voice in this section changed to “you may …” as a opposite to a third person used elsewhere.

-- Section 4.3.  Typo. s/has has/has/

-- Section 6.4.  Typo. s/Extention/Extension/

[Ballot discuss]
Thank you for the work put into this document.

Special thanks for the doc shepherd write-up , which was really useful about the WG history.

Please find below one blocking DISCUSS points (which should be solved easily), one non-blocking COMMENT point (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 2.1.10 --
About "Client IP (cdniip) claim", I really wonder whether this could be used in real life as some IPv4 Carrier-Grade NAT (CGN) have a large pool of "public" IPv4 addresses that could select different public IPv4 addresses if badly designed. How will it work with dual-stack UAs where some connections could be over IPv4 and some over IPv6 ? Now to mention a dual-home (Wi-Fi & mobile data) UA ? Or what if the dCDN is between the UA and the CGN (assuming that the uCDN or CSP are upstream of the CGN) ?

Also, "If the received signed JWT contains a Client IP claim" uses singular rather than "one or several"

I also noted that Section 7 (security considerations) puts some restrictions on the usefulness of cdniip.

I would welcome some applicability statements on the use of cdniip.

[Ballot comment]
== COMMENTS ==

-- Section 1.3 --
To be honest, I fail to understand the meaning (hence the value) of figure 3.


== NITS ==

I am afraid that the email address kleung@cisco.com is outdated.

-- Section 1 --
Is CDNI "interconnected CDNs (CDNI)" or "CDN Interconnection (CDNI)" ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cdni-uri-signing-21. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

First, in the CDNI Payload Types registry on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

https://www.iana.org/assignments/cdni-parameters/

a single, new registration will be made as follows:

Payload type: MI.UriSigning
Reference: [ RFC-to-be ]

As this document requests registrations in a or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the CDNI Logging record-types registry also on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

https://www.iana.org/assignments/cdni-parameters/

a single, new registration will be made as follows:

record-types: cdni_http_request_v2
Description: Extension to CDNI Logging Record version 1 for content delivery using HTTP, to include URI Signing logging fields
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the CDNI Logging Field Names registry also on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

https://www.iana.org/assignments/cdni-parameters/

two, new registrations will be made as follows:

Field Name: s-uri-signing
Reference: [ RFC-to-be ]

Field Name: s-uri-signing-deny-reason
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, a new registry is to be created called the CDNI URI Signing Verification Code registry. The new registry will be located on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

https://www.iana.org/assignments/cdni-parameters/

The new registry will be managed via Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

+-------+-----------------+-----------------------------------------------+
| Value | Reference | Description |
+-------+-----------------+-----------------------------------------------+
| 000 | [ RFC-to-be ] | No signed JWT verification performed |
| 200 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | verified |
| 400 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of incorrect signature |
| 401 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Issuer enforcement |
| 402 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Subject enforcement |
| 403 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Audience enforcement |
| 404 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Expiration Time |
| | | enforcement |
| 405 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Not Before enforcement |
| 406 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Issued At enforcement |
| 407 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Nonce enforcement |
| 408 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Version enforcement |
| 409 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Critical Extention |
| | | enforcement |
| 410 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of Client IP enforcement |
| 411 | [ RFC-to-be ] | Signed JWT verification performed and |
| | | rejected because of URI Container enforcement |
| 500 | [ RFC-to-be ] | Unable to perform signed JWT verification |
| | | because of malformed URI |
+-------+-----------------+-----------------------------------------------+

Fifth, a new registry is to be created called the CDNI URI Signing Signed Token Transport registry. The new registry will be located on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

https://www.iana.org/assignments/cdni-parameters/

The new registry will be managed via Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

+-------+-------------------------------------------+---------------+
| Value | Description | Reference |
+-------+-------------------------------------------+---------------+
| 0 | Designates token transport is not enabled | [ RFC-to-be ] |
| 1 | Designates token transport via cookie | [ RFC-to-be ] |
+-------+-------------------------------------------+---------------+

IANA Question --> What is the maximum value for this new registry?

Sixth, in the JSON Web Token Claims registry on the JSON Web Token (JWT) registry page located at:

https://www.iana.org/assignments/jwt/

seven, new claims are to be registered as follows:

Claim Name: cdniv
Claim Description: CDNI Claim Set Version
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.8 ]

Claim Name: cdnicrit
Claim Description: CDNI Critical Claims Set
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.9 ]

Claim Name: cdniip
Claim Description: CDNI IP Address
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.10 ]

Claim Name: cdniuc
Claim Description: CDNI URI Container
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.11 ]

Claim Name: cdniets
Claim Description: CDNI Expiration Time Setting for Signed Token Renewal
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.12 ]

Claim Name: cdnistt
Claim Description: CDNI Signed Token Transport Method for Signed Token Renewal
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.13 ]

Claim Name: cdnistd
Claim Description: CDNI Signed Token Depth
Change Controller: IESG
Reference: [ RFC-to-be; Section 2.1.14 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-19):

From: The IESG
To: IETF-Announce
CC: barryleiba@gmail.com, cdni-chairs@ietf.org, cdni@ietf.org, draft-ietf-cdni-uri-signing@ietf.org, kevin.j.ma@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (URI Signing for Content Delivery Network Interconnection (CDNI)) to Proposed Standard


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document: - 'URI Signing
for Content Delivery Network Interconnection (CDNI)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes how the concept of URI Signing supports the
  content access control requirements of Content Delivery Network
  Interconnection (CDNI) and proposes a URI Signing method as a JSON
  Web Token (JWT) profile.

  The proposed URI Signing method specifies the information needed to
  be included in the URI to transmit the signed JWT, as well as the
  claims needed by the signed JWT to authorize a User Agent (UA).  The
  mechanism described can be used both in CDNI and single Content
  Delivery Network (CDN) scenarios.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2603/
  https://datatracker.ietf.org/ipr/4628/

Document Shepherd: Kevin J. Ma

Responsible AB: Barry Leiba

This document defines a standard for URI signing to enable interoperability between interconnected CDNs.  We are requesting publication as "Proposed Standard" as we feel it has been extensively reviewed and vetted by the WG.  The draft has undergone significant rewrite multiple times as a result of the reviews and implementations.  There are commercial implementations, as well as interest and review by other SDOs (e.g., the Streaming Video Alliance and the MPEG WG, see https://datatracker.ietf.org/liaison/1413/).  During the most recent rewrite, over the course of many IETFs, the authors, interested parties, and WG discussed all aspects of the switch to JWT.  In the more recent revisions, non-editorial changes were primarily the result of implementation findings.  At this point, the WG feels that the document is mature and complete.

The document originally went to WGLC in July 2016.  In an pre-sec-dir review, Matt Miller had "reinventing the wheel" (more specifically, reinventing crypto wheels by non-security folks) concerns (see https://mailarchive.ietf.org/arch/msg/cdni/3xTSo1OzQyFf6ky8gj8kMxPTU1Q/).  At that time, it was decided to rewrite the draft to rely on JWT for the security aspects.  This greatly simplified the security aspects of the draft to specifying just the JWT claims needed to implement the CDNI security policies.

There are known security limitations with URI signing, and they are documented in the Introduction and Security Considerations sections.  If used responsibly for its intended purpose, URI signing serves a specific function providing basic access control, useful in protecting the CDN itself (though not necessarily the content being served by the CDN).  Though these limitations are often misunderstood by or misrepresented to content owners, URI signing is widely used for its intended (stated) purpose by network operators.  Because of this wide use, the WG feels that standardizing URI signing is important for interoperability.

As Matt Miller was deeply involved in the rewrite, the WG feels that the security aspects should be well vetted at this point.

The other major change since the original WGLC was the inclusion of Token Renewal for HTTP Addaptive Streaming (HAS).  Originally, the WG decided to avoid HAS in all WG documents, because we could not come to a concensus on how to address it, and there was concern that a lot of IPR would be implicated.  For URI signing, an IPR disclosure was made on HAS related conten (see https://datatracker.ietf.org/ipr/2603/), and the WG decided to split out the IPR encumbered portion at IETF-93 (see https://tools.ietf.org/wg/cdni/minutes?item=minutes-93-cdni.html).  The IPR disclosure was subsequently updated (see https://datatracker.ietf.org/ipr/2806/) removing the royalties and the WG decided to re-incorporate the IPR encumbered portion at IETF-96 (see https://tools.ietf.org/wg/cdni/minutes?item=minutes-96-cdni.html).

Because HAS has become such a significant portion of CDN traffic, the WG felt that HAS support was important to include and the updated IPR terms were deemed acceptable.

The authors have confirmed that there is no other known undisclosed IPR related to the contents of this document.

There are no downward references in the document, and I agree with the normative vs informative reference designations.  I suppose it could be argued that the CDNI problem statement and requirements documents are normative to URI Signing's purpose, but they don't really affect the protocol specifics so they are listed as informative.  Similarly, the reference to the CDNI Request Routing interface, only used to say that there is no dependency on the CDNI Request Routing interface also seems fine as non-normative.

This document registers a new CDNI Payload Type in our IANA registry, for the purpose of identifying URI Signing CDNI Metadata and advertising URI Signing CDNI Capabilities.  This is inline with the intended purpose of the registry.  I am the creator of and one of the two expert reviewers for that registry and approve of this registration.

This document registers a new CDNI Logging Record Type and two associated CDNI Logging Field Names.  These registrations are inline with the intended extensibility design of CDNI Logging.  I am  one of the two expert reviewers for these registries and approve of this registration.

This document registers seven new claims in the JSON Web Token Claims registry.  The authors have discussed the registrations with Brian Campbell, one of the Expert reviewers for the JSON Web Token Claims registry, and he approved of the registrations.

This document creates two new IANA registries: the CDNI URI Signing Verification Code registry and the CDNI URI Signing Signed Token Transport registry.  Both registries are defined as Specification Required.  Phil Sorber and I volunteer to be expert reviewers for both registries.

The CDNI URI Signing Verification Code registry is for registering error codes reported in CDNI logs.  URI Signing allows for extension claims to be defined in the future.  The error codes correspond one-to-one with claims.  Though future extensions would likely be defined in RFCs, and new error codes could be defined in those RFCs, a registry seemed like a better way to prevent overlapping or duplicate error codes.

The CDNI URI Signing Signed Token Transport registry is for registering valid values for the CDNI Signed Token Transport claim.  There are only two values initially defined: none and cookie.  The intent of the registry is to allow for future extensibility.  Though cookies were the proposed implementation for HAS support, the WG did not wanted to assume cookies would always be the best solution.

Document Shepherd: Kevin J. Ma

Responsible AB: Barry Leiba

This document defines a standard for URI signing to enable interoperability between interconnected CDNs.  We are requesting publication as "Proposed Standard" as we feel it has been extensively reviewed and vetted by the WG.  The draft has undergone significant rewrite multiple times as a result of the reviews and implementations.  There are commercial implementations, as well as interest and review by other SDOs (e.g., the Streaming Video Alliance and the MPEG WG, see https://datatracker.ietf.org/liaison/1413/).  During the most recent rewrite, over the course of many IETFs, the authors, interested parties, and WG discussed all aspects of the switch to JWT.  In the more recent revisions, non-editorial changes were primarily the result of implementation findings.  At this point, the WG feels that the document is mature and complete.

The document originally went to WGLC in July 2016.  In an pre-sec-dir review, Matt Miller had "reinventing the wheel" (more specifically, reinventing crypto wheels by non-security folks) concerns (see https://mailarchive.ietf.org/arch/msg/cdni/3xTSo1OzQyFf6ky8gj8kMxPTU1Q/).  At that time, it was decided to rewrite the draft to rely on JWT for the security aspects.  This greatly simplified the security aspects of the draft to specifying just the JWT claims needed to implement the CDNI security policies.

There are known security limitations with URI signing, and they are documented in the Introduction and Security Considerations sections.  If used responsibly for its intended purpose, URI signing serves a specific function providing basic access control, useful in protecting the CDN itself (though not necessarily the content being served by the CDN).  Though these limitations are often misunderstood by or misrepresented to content owners, URI signing is widely used for its intended (stated) purpose by network operators.  Because of this wide use, the WG feels that standardizing URI signing is important for interoperability.

As Matt Miller was deeply involved in the rewrite, the WG feels that the security aspects should be well vetted at this point.

The other major change since the original WGLC was the inclusion of Token Renewal for HTTP Addaptive Streaming (HAS).  Originally, the WG decided to avoid HAS in all WG documents, because we could not come to a concensus on how to address it, and there was concern that a lot of IPR would be implicated.  For URI signing, an IPR disclosure was made on HAS related conten (see https://datatracker.ietf.org/ipr/2603/), and the WG decided to split out the IPR encumbered portion at IETF-93 (see https://tools.ietf.org/wg/cdni/minutes?item=minutes-93-cdni.html).  The IPR disclosure was subsequently updated (see https://datatracker.ietf.org/ipr/2806/) removing the royalties and the WG decided to re-incorporate the IPR encumbered portion at IETF-96 (see https://tools.ietf.org/wg/cdni/minutes?item=minutes-96-cdni.html).

Because HAS has become such a significant portion of CDN traffic, the WG felt that HAS support was important to include and the updated IPR terms were deemed acceptable.

The authors have confirmed that there is no other known undisclosed IPR related to the contents of this document.

There are no downward references in the document, and I agree with the normative vs informative reference designations.  I suppose it could be argued that the CDNI problem statement and requirements documents are normative to URI Signing's purpose, but they don't really affect the protocol specifics so they are listed as informative.  Similarly, the reference to the CDNI Request Routing interface, only used to say that there is no dependency on the CDNI Request Routing interface also seems fine as non-normative.

This document registers a new CDNI Payload Type in our IANA registry, for the purpose of identifying URI Signing CDNI Metadata and advertising URI Signing CDNI Capabilities.  This is inline with the intended purpose of the registry.  I am the creator of and one of the two expert reviewers for that registry and approve of this registration.

This document registers a new CDNI Logging Record Type and two associated CDNI Logging Field Names.  These registrations are inline with the intended extensibility design of CDNI Logging.  I am  one of the two expert reviewers for these registries and approve of this registration.

This document registers seven new claims in the JSON Web Token Claims registry.  The authors have discussed the registrations with Brian Campbell, one of the Expert reviewers for the JSON Web Token Claims registry, and he approved of the registrations.

This document creates two new IANA registries: the CDNI URI Signing Verification Code registry and the CDNI URI Signing Signed Token Transport registry.  Both registries are defined as Specification Required.  Phil Sorber and I volunteer to be expert reviewers for both registries.

The CDNI URI Signing Verification Code registry is for registering error codes reported in CDNI logs.  URI Signing allows for extension claims to be defined in the future.  The error codes correspond one-to-one with claims.  Though future extensions would likely be defined in RFCs, and new error codes could be defined in those RFCs, a registry seemed like a better way to prevent overlapping or duplicate error codes.

The CDNI URI Signing Signed Token Transport registry is for registering valid values for the CDNI Signed Token Transport claim.  There are only two values initially defined: none and cookie.  The intent of the registry is to allow for future extensibility.  Though cookies were the proposed implementation for HAS support, the WG did not wanted to assume cookies would always be the best solution.

Document Shepherd: Kevin J. Ma

Responsible AB: Barry Leiba

This document defines a standard for URI signing to enable interoperability between interconnected CDNs.  We are requesting publication as "Proposed Standard" as we feel it has been extensively reviewed and vetted by the WG.  The draft has undergone significant rewrite multiple times as a result of the reviews and implementations.  There are commercial implementations, as well as interest and review by other SDOs (e.g., the Streaming Video Alliance and the MPEG WG, see https://datatracker.ietf.org/liaison/1413/).  During the most recent rewrite, over the course of many IETFs, the authors, interested parties, and WG discussed all aspects of the switch to JWT.  In the more recent revisions, non-editorial changes were primarily the result of implementation findings.  At this point, the WG feels that the document is mature and complete.

The document originally went to WGLC in July 2016.  In an pre-sec-dir review, Matt Miller had "reinventing the wheel" (more specifically, reinventing crypto wheels by non-security folks) concerns (see https://mailarchive.ietf.org/arch/msg/cdni/3xTSo1OzQyFf6ky8gj8kMxPTU1Q/).  At that time, it was decided to rewrite the draft to rely on JWT for the security aspects.  This greatly simplified the security aspects of the draft to specifying just the JWT claims needed to implement the CDNI security policies.

There are known security limitations with URI signing, and they are documented in the Introduction and Security Considerations sections.  If used responsibly for its intended purpose, URI signing serves a specific function providing basic access control, useful in protecting the CDN itself (though not necessarily the content being served by the CDN).  Though these limitations are often misunderstood by or misrepresented to content owners, URI signing is widely used for its intended (stated) purpose by network operators.  Because of this wide use, the WG feels that standardizing URI signing is important for interoperability.

As Matt Miller was deeply involved in the rewrite, the WG feels that the security aspects should be well vetted at this point.

The other major change since the original WGLC was the inclusion of Token Renewal for HTTP Addaptive Streaming (HAS).  Originally, the WG decided to avoid HAS in all WG documents, because we could not come to a concensus on how to address it, and there was concern that a lot of IPR would be implicated.  For URI signing, an IPR disclosure was made on HAS related conten (see https://datatracker.ietf.org/ipr/2603/), and the WG decided to split out the IPR encumbered portion at IETF-93 (see https://tools.ietf.org/wg/cdni/minutes?item=minutes-93-cdni.html).  The IPR disclosure was subsequently updated (see https://datatracker.ietf.org/ipr/2806/) removing the royalties and the WG decided to re-incorporate the IPR encumbered portion at IETF-96 (see https://tools.ietf.org/wg/cdni/minutes?item=minutes-96-cdni.html).

Because HAS has become such a significant portion of CDN traffic, the WG felt that HAS support was important to include and the updated IPR terms were deemed acceptable.

The authors have confirmed that there is no other known undisclosed IPR related to the contents of this document.

There are no downward references in the document, and I agree with the normative vs informative reference designations.  I suppose it could be argued that the CDNI problem statement and requirements documents are normative to URI Signing's purpose, but they don't really affect the protocol specifics so they are listed as informative.  Similarly, the reference to the CDNI Request Routing interface, only used to say that there is no dependency on the CDNI Request Routing interface also seems fine as non-normative.

This document registers a new CDNI Payload Type in our IANA registry, for the purpose of identifying URI Signing CDNI Metadata and advertising URI Signing CDNI Capabilities.  This is inline with the intended purpose of the registry.  I am the creator of and one of the two expert reviewers for that registry and approve of this registration.

This document registers a new CDNI Logging Record Type and two associated CDNI Logging Field Names.  These registrations are inline with the intended extensibility design of CDNI Logging.  I am  one of the two expert reviewers for these registries and approve of this registration.

This document registers seven new claims in the JSON Web Token Claims registry.  The authors have discussed the registrations with Brian Campbell, one of the Expert reviewers for the JSON Web Token Claims registry, and he approved of the registrations.

This document creates two new IANA registries: the CDNI URI Signing Verification Code registry and the CDNI URI Signing Signed Token Transport registry.  Both registries are defined as Specification Required.

The CDNI URI Signing Verification Code registry is for registering error codes reported in CDNI logs.  URI Signing allows for extension claims to be defined in the future.  The error codes correspond one-to-one with claims.  Though future extensions would likely be defined in RFCs, and new error codes could be defined in those RFCs, a registry seemed like a better way to prevent overlapping or duplicate error codes.

The CDNI URI Signing Signed Token Transport registry is for registering valid values for the CDNI Signed Token Transport claim.  There are only two values initially defined: none and cookie.  The intent of the registry is to allow for future extensibility.  Though cookies were the proposed implementation for HAS support, the WG did not wanted to assume cookies would always be the best solution.

Request for posting confirmation emailed to previous authors: "Michel Fisher" , "Bill Downey" , cdni-chairs@ietf.org, "Kent Leung" , "Ray van Brandenburg" , "Francois Le Faucheur"