From nobody Mon Mar 11 14:55:41 2019 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559F21311F7 for ; Mon, 11 Mar 2019 14:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uglgK2hbPtcw for ; Mon, 11 Mar 2019 14:55:23 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 8CB9D13121C for ; Mon, 11 Mar 2019 14:55:23 -0700 (PDT) Received: (qmail 76317 invoked by uid 99); 11 Mar 2019 21:55:23 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Mar 2019 21:55:23 +0000 Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 4B8863563 for ; Mon, 11 Mar 2019 21:55:22 +0000 (UTC) Received: by mail-io1-f54.google.com with SMTP id x7so263699ioh.4 for ; Mon, 11 Mar 2019 14:55:22 -0700 (PDT) X-Gm-Message-State: APjAAAWSZD1sREIBs7G55fzr/dnmcNIfenM1fiiFlMRzEKWyq35dE/sa N2kcZTS/cTduAjK9GEZ033R9dON0vcqREvto3SY= X-Google-Smtp-Source: APXvYqza/VgG2Y9uqYdFgLmNICgaFyzfYcpXZq2nIGM7tRprmIACyal6ZNVUXjAxWrkfSnKbCuEAxe9qHRpUGZ2zi0s= X-Received: by 2002:a6b:f81a:: with SMTP id o26mr16399458ioh.156.1552341321914; Mon, 11 Mar 2019 14:55:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Mon, 11 Mar 2019 15:55:10 -0600 X-Gmail-Original-Message-ID: Message-ID: To: "Kolev, Nikola" , "" Content-Type: multipart/alternative; boundary="000000000000101f4b0583d8a11e" Archived-At: Subject: Re: [CDNi] Comments on draft 16 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:55:32 -0000 --000000000000101f4b0583d8a11e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, my mistake on the reply. Didn't go to the list the first time. On Mon, Mar 11, 2019 at 3:54 PM Phil Sorber wrote: > Document editor hat on... > > Sorry for the late reply. Responses inline below. > > On Wed, Feb 6, 2019 at 9:40 AM Kolev, Nikola > wrote: > >> Hello, >> >> >> >> I am not sure what the protocol for providing feedback to this memo is s= o >> I have included it in this email below. Please let me know what the >> preferred method is and I would resubmit. >> >> >> >> Thanks, >> >> Nikola Kolev >> >> >> >> (Re) >> >> 2.1.2. Subject (sub) claim >> >> >> >> 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. >> >> >> >> Comment: Why? The subject claim does not necessarily need to contain PII= . >> Also, it would be better that the specification leaves this claim's >> encoding to "service providers" which may choose a "more optimal", than >> JWE, encoding scheme even in the case where the claim carries PII and (s= ome >> portion of) the claim is encrypted. >> >> > Definitions if PII vary greatly. The IETF is very privacy conscious as an > organization. It was decided that the best course of action is to treat t= he > entire claim as PII regardless. Consider that it's likely a unique > identifier, which may not be name/IP address but can be uniquely > identifying anyway. And since we are so privacy conscious, we wanted to > specify a method of encryption that we deemed safe instead of letting > operators use ROT13 and calling it a day. > > >> >> >> (Re) >> >> 2.1.4. Expiry Time (exp) claim >> >> >> >> Expiry Time (exp) [optional] - The semantics in [RFC7519] >> >> Section 4.1.4 MUST be followed, though URI Signing implementations >> >> .. .. or if the Expiry Time in >> >> the signed JWT corresponds to a time earlier than the time of the >> >> content request, the CDN MUST reject the request. .. .. .. >> >> >> >> Comment: If I am not mistaken the `exp` claim carries **on** or after >> semantics. Hence the memo should read not just **earlier**, as on should >> result in rejection as well. >> > > Noted. > > >> (Re) >> >> 2.1.9. CDNI Critical Claims Set (cdnicrit) claim >> >> >> >> CDNI Critical Claims Set (cdnicrit) [optional] - The cdnicrit claim >> >> indicates that extensions to this specification are being used that >> >> MUST be understood and processed. Its value is a comma separated >> >> listing of claims in the Signed JWT that use those extensions. >> >> >> >> >> >> Comment: Should be specified as list. Same as the `crit` header claim, >> https://tools.ietf.org/html/rfc7515#section-4.1.11. "Its value is a >> comma separated..." could be misinterpreted as a StringOrURI carrying a = CSV >> value. >> > > The working group decided that the JWT object should be flat, which means > no lists. It would be correct to interpret this as a StringOrURI carrying= a > CSV value. You will note that we did not link back to the "crit" claim in > 7515 that you referenced, and explicitly named it "cdnicrit". > > >> >> >> (Re) >> >> 2.1.11. CDNI URI Container (cdniuc) claim >> >> >> >> URI Container (cdniuc) [optional] - Container for holding the URI >> >> representation before a URI Signing Package is added. This >> >> representation can take one of several forms detailed in >> >> Section 2.1.15. If the URI regex .. >> >> >> >> Comment: URI regex is only one of the forms that the claim can assume. >> > > Noted. That looks vestigial. The prior sentence has the correct semantics= . > > >> >> >> (Re) >> >> 6.4. CDNI URI Signing Signed Token Transport >> >> >> >> The "CDNI URI Signing Signed Token Transport" namespace defines the >> >> valid values that may be in the Signed Token Transport (cdnistt) JWT >> >> claim. >> >> >> >> The following table defines the initial Enforcement Information >> >> Elements: >> >> >> >> +-------+-------------------------------------------+---------+ >> >> | Value | Description | RFC | >> >> +-------+-------------------------------------------+---------+ >> >> | 0 | Designates token transport is not enabled | RFCthis | >> >> | 1 | Designates token transport via cookie | RFCthis | >> >> +-------+-------------------------------------------+---------+ >> >> >> >> Comment/Question: I would imagine a system where the CDN is not the >> authority that handles token renewals, but instead the CDN sends the use= r >> agent back to the original token issuer. Can the working group consider >> this architecture and expand the list of =E2=80=9Ctoken transport=E2=80= =9D mechanisms, to >> include for example HTTP redirects? >> > > HTTP redirects have been discussed, but a specific proposal has never bee= n > put forward. The publishing of this document does not preclude such a > proposal from taking shape at a later date. > > >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> > --000000000000101f4b0583d8a11e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, my mistake on the reply. Didn't go to the = list the first time.

On Mon, Mar 11, 2019 at 3:54 PM Phil Sorber <sorber@apache.org> wrote:
Do= cument editor hat on...

Sorry for the late rep= ly. Responses inline below.

On Wed, Feb 6, 2019 at 9:40 AM Kolev, Nikola <= ;Nikola_Kolev= @comcast.com> wrote:

Hello,

=C2=A0

I am not sure what the protocol for providing feedba= ck to this memo is so I have included it in this email below. Please let me= know what the preferred method is and I would resubmit.

=C2=A0

Thanks,

Nikola Kolev

=C2=A0

(Re)

2.1.2.=C2=A0=C2=A0Subject (sub) claim<= /span>

=C2=A0

=C2=A0=C2=A0 Subject (sub) [optional] - The semantic= s in [RFC7519] Section 4.1.2

=C2=A0=C2=A0 MUST be followed.=C2=A0=C2=A0If this cl= aim is used, it MUST be a JSON Web

=C2=A0=C2=A0 Encryption (JWE [RFC7516]) Object in co= mpact serialization form,

=C2=A0=C2=A0 because it contains personally identifi= able information.

=C2=A0

Comment: Why? The subject claim does not necessarily= need to contain PII. Also, it would be better that the specification leave= s this claim's encoding to "service providers" which may choose a "more optimal", than JWE, encoding scheme eve= n in the case where the claim carries PII and (some portion of) the claim i= s encrypted.


=
Definitions if PII vary greatly. The IETF is very privacy consci= ous as an organization. It was decided that the best course of action is to= treat the entire claim as PII regardless. Consider that it's likely a = unique identifier, which may not be name/IP address but can be uniquely ide= ntifying anyway. And since we are so privacy conscious, we wanted to specif= y a method of encryption that we deemed safe instead of letting operators u= se ROT13 and calling it a day.
=C2=A0

=C2=A0

(Re)

2.1.4.=C2=A0=C2=A0Expiry Time (exp) claim<= /u>

=C2=A0

=C2=A0=C2=A0 Expiry Time (exp) [optional] - The sema= ntics in [RFC7519]

=C2=A0=C2=A0 Section 4.1.4 MUST be followed, though = URI Signing implementations

=C2=A0=C2=A0 .. .. or if the Expiry Time in

=C2=A0=C2=A0 the signed JWT corresponds to a time ea= rlier than the time of the

=C2=A0=C2=A0 content request, the CDN MUST reject th= e request. .. .. ..

=C2=A0

Comment: If I am not mistaken the `exp` claim carrie= s **on** or after semantics. Hence the memo should read not just **earlier*= *, as on should result in rejection as well.


Noted.
=C2=A0

(Re)

2.1.9.=C2=A0=C2=A0CDNI Critical Claims Set (cdnicrit= ) claim

=C2=A0

=C2=A0=C2=A0 CDNI Critical Claims Set (cdnicrit) [op= tional] - The cdnicrit claim

=C2=A0=C2=A0 indicates that extensions to this speci= fication are being used that

=C2=A0=C2=A0 MUST be understood and processed.=C2=A0= =C2=A0Its value is a comma separated

=C2=A0=C2=A0 listing of claims in the Signed JWT tha= t use those extensions.

=C2=A0

=C2=A0

Comment: Should be specified as list. Same as the `c= rit` header claim, https://tools.ietf.org/html/rfc7515#section-4.1.11. "Its val= ue is a comma separated..." could be misinterpreted as a StringOrURI c= arrying a CSV value.


The working group decided that the JWT object should be flat, which means = no lists. It would be correct to interpret this as a StringOrURI carrying a= CSV value. You will note that we did not link back to the "crit"= claim in 7515 that you referenced, and explicitly named it "cdnicrit&= quot;.
=C2=A0

=C2=A0

(Re)

2.1.11.=C2=A0=C2=A0CDNI URI Container (cdniuc) claim=

=C2=A0

=C2=A0=C2=A0 URI Container (cdniuc) [optional] - Con= tainer for holding the URI

=C2=A0=C2=A0 representation before a URI Signing Pac= kage is added.=C2=A0=C2=A0This

=C2=A0=C2=A0 representation can take one of several = forms detailed in

=C2=A0=C2=A0 Section 2.1.15.=C2=A0=C2=A0If the URI r= egex ..

=C2=A0

Comment: URI regex is only one of the forms that the= claim can assume.


N= oted. That looks vestigial. The prior sentence has the correct semantics.
=C2=A0
=

=C2=A0

(Re)

6.4.=C2=A0=C2=A0CDNI URI Signing Signed Token Transp= ort

=C2=A0

=C2=A0=C2=A0 The "CDNI URI Signing Signed Token= Transport" namespace defines the

=C2=A0=C2=A0 valid values that may be in the Signed = Token Transport (cdnistt) JWT

=C2=A0=C2=A0 claim.

=C2=A0

=C2=A0=C2=A0 The following table defines the initial= Enforcement Information

=C2=A0=C2=A0 Elements:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0+-------+-------------------= ------------------------+---------+

=C2=A0=C2=A0=C2=A0=C2=A0| Value | Description=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | RFC=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0+-------+-------------------= ------------------------+---------+

=C2=A0=C2=A0=C2=A0=C2=A0| 0=C2=A0=C2=A0=C2=A0=C2=A0 = | Designates token transport is not enabled | RFCthis |

=C2=A0=C2=A0=C2=A0=C2=A0| 1=C2=A0=C2=A0=C2=A0=C2=A0 = | Designates token transport via cookie=C2=A0=C2=A0=C2=A0=C2=A0 | RFCthis |=

=C2=A0=C2=A0=C2=A0=C2=A0+-------+-------------------= ------------------------+---------+

=C2=A0

Comment/Question: I would imagine a system where the= CDN is not the authority that handles token renewals, but instead the CDN = sends the user agent back to the original token issuer. Can the working group consider this architecture and expand the li= st of =E2=80=9Ctoken transport=E2=80=9D mechanisms, to include for example = HTTP redirects?


HTTP= redirects have been discussed, but a specific proposal has never been put = forward. The publishing of this document does not preclude such a proposal = from taking shape at a later date.
=C2=A0

=C2=A0<= /span>

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000101f4b0583d8a11e-- From nobody Mon Mar 11 15:45:45 2019 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08F612870E for ; Mon, 11 Mar 2019 15:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5AwAMEe9-yE for ; Mon, 11 Mar 2019 15:45:43 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id E90B51286C8 for ; Mon, 11 Mar 2019 15:45:42 -0700 (PDT) Received: (qmail 53676 invoked by uid 99); 11 Mar 2019 22:45:42 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Mar 2019 22:45:42 +0000 Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 543553564 for ; Mon, 11 Mar 2019 22:45:41 +0000 (UTC) Received: by mail-io1-f41.google.com with SMTP id c4so328813ioh.9 for ; Mon, 11 Mar 2019 15:45:41 -0700 (PDT) X-Gm-Message-State: APjAAAUHoPZ1wAOOTN2/zU3vKlFzXz37nGr0hQogc+y5AytioJekk/Gf OYQstRFQG4LE9g9f4oLNyRJADyh3/3JKZkvLaE8= X-Google-Smtp-Source: APXvYqyNC0jT7+nLf+/Z2TS261Fe73ISlDxKCMPjM/Hmo0lCfAZWhizfjEo/S2cs+dI+in39HCPprbrYF+jZxa6Ck2Y= X-Received: by 2002:a6b:d109:: with SMTP id l9mr19321263iob.108.1552344340810; Mon, 11 Mar 2019 15:45:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Mon, 11 Mar 2019 16:45:29 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Chris Lemmons Cc: "" Content-Type: multipart/alternative; boundary="00000000000000d1120583d955b8" Archived-At: Subject: Re: [CDNi] URI Signing Logging Codes X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 22:45:45 -0000 --00000000000000d1120583d955b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2019 at 12:06 PM Chris Lemmons wrote: > It looks like the Logging Codes in =C2=A74.5 are a bit behind some other > recent changes. Some notes: > > 403 refers to "Regular Expression" enforcement, but it's possible a > different container was used. If this is to refer just to regexen, > that's fine, but then we'd need a code for mismatched other container. > I suspect this should just say, "cdniuc enforcement". > It appears this is very old text. Also, there seem to be at least a couple places we assumed Regex when other options are available. > > These claims can be used for enforcement, but don't have an associated > code (with examples): > sub: The subject isn't authorized for content on the dCDN. > aud: The token was presented to the wrong dCDN. > jti: A token is reused. > cdniv: An unsupported token version number is presented. > cdnicrit: An unsupported extension is used. > Yes, these should be added. > > Additionally, although the 500 code can be used for a malformed URI, > it's unclear what should be logged when the claim formulation is > unacceptable, for example, a negative cdnistd claim or a cdnistt > without a cdniets claim. In fact, it's not entirely clear from the > text whether a claim formulated like this MAY, MUST, or MUST NOT be > rejected. > > And if a token is rejected for a reason not listed, presumably as a > result of an extension, what number should be logged? Should we have a > "catch-all"? > I think 500 is the catch-all. As in, "I couldn't understand this." > > What if a token is invalid for multiple reasons? Which code takes > precedence? > I don't think that's particularly important. I think whatever you first find invalid is what you should log. There is no reason to continue to check other claims if you have found something to be invalid. If this is for diagnostics then once you correct one thing, the next problem will show itself. > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --00000000000000d1120583d955b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 23, 2019 at 12:06 PM Chri= s Lemmons <alficles@gmail.com&= gt; wrote:
It lo= oks like the Logging Codes in =C2=A74.5 are a bit behind some other
recent changes. Some notes:

403 refers to "Regular Expression" enforcement, but it's poss= ible a
different container was used. If this is to refer just to regexen,
that's fine, but then we'd need a code for mismatched other contain= er.
I suspect this should just say, "cdniuc enforcement".

It appears this is very old text. Also, there seem= to be at least a couple places we assumed Regex when other options are ava= ilable.
=C2=A0

These claims can be used for enforcement, but don't have an associated<= br> code (with examples):
=C2=A0 sub: The subject isn't authorized for content on the dCDN.
=C2=A0 aud: The token was presented to the wrong dCDN.
=C2=A0 jti: A token is reused.
=C2=A0 cdniv: An unsupported token version number is presented.
=C2=A0 cdnicrit: An unsupported extension is used.
Yes, these should be added.
=C2=A0

Additionally, although the 500 code can be used for a malformed URI,
it's unclear what should be logged when the claim formulation is
unacceptable, for example, a negative cdnistd claim or a cdnistt
without a cdniets claim. In fact, it's not entirely clear from the
text whether a claim formulated like this MAY, MUST, or MUST NOT be
rejected.

And if a token is rejected for a reason not listed, presumably as a
result of an extension, what number should be logged? Should we have a
"catch-all"?

I think 500 is t= he catch-all. As in, "I couldn't understand this."
<= div>=C2=A0

What if a token is invalid for multiple reasons? Which code takes precedenc= e?

I don't think that's particu= larly important. I think whatever you first find invalid is what you should= log. There is no reason to continue to check other claims if you have foun= d something to be invalid. If this is for diagnostics then once you correct= one thing, the next problem will show itself.
=C2=A0

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--00000000000000d1120583d955b8-- From nobody Mon Mar 11 16:14:01 2019 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD369126CAD; Mon, 11 Mar 2019 16:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cdni@ietf.org Message-ID: <155234603986.23130.11254805984463504417@ietfa.amsl.com> Date: Mon, 11 Mar 2019 16:13:59 -0700 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-17.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:14:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : URI Signing for CDN Interconnection (CDNI) Authors : Ray van Brandenburg Kent Leung Phil Sorber Filename : draft-ietf-cdni-uri-signing-17.txt Pages : 40 Date : 2019-03-11 Abstract: This document describes how the concept of URI signing supports the content access control requirements of 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 UA. The mechanism described can be used both in CDNI and single CDN scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-17 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 16:17:50 2019 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA735124B19 for ; Mon, 11 Mar 2019 16:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2zQonmDCSEj for ; Mon, 11 Mar 2019 16:17:48 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id E048012797A for ; Mon, 11 Mar 2019 16:17:47 -0700 (PDT) Received: (qmail 3981 invoked by uid 99); 11 Mar 2019 23:17:46 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Mar 2019 23:17:46 +0000 Received: from mail-it1-f169.google.com (mail-it1-f169.google.com [209.85.166.169]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 867EC44DC for ; Mon, 11 Mar 2019 23:17:45 +0000 (UTC) Received: by mail-it1-f169.google.com with SMTP id z131so1406436itf.5 for ; Mon, 11 Mar 2019 16:17:45 -0700 (PDT) X-Gm-Message-State: APjAAAWL3Z4YgCw9F5CrDC52P33x1EfA8KD9fXYibJEHSg1wICIioaxB Eegp2s8T3AFZEzzSiTb6/reWrr4tY3bp0W4YjAI= X-Google-Smtp-Source: APXvYqyFBROyVu5FH/+ut5dB1wl43rxj6H1dEWYdO6G4kJXqL2kwGoHZ4ztVI06/m+BZHHZ/cxkS9hiUfXhV0MXGAgQ= X-Received: by 2002:a02:c60b:: with SMTP id i11mr19687949jan.118.1552346265056; Mon, 11 Mar 2019 16:17:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Mon, 11 Mar 2019 17:17:33 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Kevin Ma Cc: "" Content-Type: multipart/alternative; boundary="000000000000b27f840583d9c771" Archived-At: Subject: Re: [CDNi] Shepherd Review of URI Signing X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 23:17:50 -0000 --000000000000b27f840583d9c771 Content-Type: text/plain; charset="UTF-8" Sorry for the delay. I've published version 17 that covers your review as well as the items you put in this thread and a few other comments on the list. Here is a link to the diff (not including your changes): https://github.com/PSUdaemon/URISigningSpec/pull/61/files Thanks. On Mon, Nov 12, 2018 at 10:36 PM Kevin Ma wrote: > one additional question: > > - section 2.1.3: Is any CDN allowed to add/modify the audience claim? Can > we add explicit text wrt who can/should modify the audience claim? > > On Tue, Nov 13, 2018 at 12:16 AM Kevin Ma > wrote: > >> trying again: https://github.com/PSUdaemon/URISigningSpec/pull/60/files >> >> On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber wrote: >> >>> Kevin, >>> >>> Your PR has been made against your own repo and not mine, thus I cannot >>> merge it. Can you create a PR with it against my repo instead? >>> >>> Thanks. >>> >>> On Sat, Nov 10, 2018 at 10:39 PM Kevin Ma >>> wrote: >>> >>>> Hi All, >>>> >>>> (As chair) As promised, I have performed a shepherd review of the >>>> latest URI Signing draft. I have submitted a pull request addressing a >>>> whole bunch of nits: >>>> https://github.com/kjmietf/URISigningSpec/pull/2/files . Three >>>> additional questions for the authors: >>>> >>>> - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be normative >>>> references? They feel normative to me. >>>> - section 2.1.10: do you want to add a reference for IPv4 address >>>> notation? >>>> - section 6.4: Are there any special instructions to the expert >>>> reviewer? Need to remove the ed note. >>>> >>>> I think that the draft will be ready for WGLC once the above issues >>>> are addressed. >>>> >>>> thanx! >>>> >>>> -- Kevin J. Ma >>>> >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>> >>> --000000000000b27f840583d9c771 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the delay. I've publis= hed version 17 that covers your review as well as the items you put in this= thread and a few other comments on the list. Here is a link to the diff (n= ot including your changes):


Thanks.

On Mon, Nov 12, 2018 at 10:36 PM Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
one addit= ional question:

- section 2.1.3: Is any CDN allowed to a= dd/modify the audience claim?=C2=A0 Can we add explicit text wrt who can/sh= ould modify the audience claim?

<= div dir=3D"ltr">On Tue, Nov 13, 2018 at 12:16 AM Kevin Ma <kevin.j.ma.ietf@gmail.com= > wrote:
=
On Sun, Nov 11, 2018 at 11:25 PM Ph= il Sorber <sorber= @apache.org> wrote:
Kevin,

Your PR ha= s been made against your own repo and not mine, thus I cannot merge it. Can= you create a PR with it against my repo instead?

= Thanks.

On Sa= t, Nov 10, 2018 at 10:39 PM Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:




_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000b27f840583d9c771-- From nobody Sun Mar 31 04:53:12 2019 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CED1F120043; Sun, 31 Mar 2019 04:53:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cdni@ietf.org Message-ID: <155403318275.12273.17586391042919500029@ietfa.amsl.com> Date: Sun, 31 Mar 2019 04:53:02 -0700 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 11:53:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : CDNI Request Routing Extensions Authors : Ori Finkelman Sanjay Mishra Filename : draft-ietf-cdni-request-routing-extensions-02.txt Pages : 11 Date : 2019-03-31 Abstract: The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery requests from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). The extensions specified in this document to the CDNI Metadata and FCI interfaces are derived from requirements raised by Open Caching but are applicable to CDNI use cases in general. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-02 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-request-routing-extensions-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 31 05:48:10 2019 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 917F212012B; Sun, 31 Mar 2019 05:48:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cdni@ietf.org Message-ID: <155403648852.12398.1165295678599423621@ietfa.amsl.com> Date: Sun, 31 Mar 2019 05:48:08 -0700 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-triggers-extensions-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 12:48:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : CDNI Control Triggers Interface Extensions Authors : Ori Finkelman Sanjay Mishra Filename : draft-ietf-cdni-triggers-extensions-02.txt Pages : 42 Date : 2019-03-31 Abstract: This document updates RFC 8007 to include generic extensions and more granular content matching options, required by the Open Caching architecture. The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery request from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). The extensions specified in this document to the CDNI Control Interface / Triggers are derived from requirements of Open Caching but are applicable to CDNI use cases in general. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-triggers-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-triggers-extensions-02 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-triggers-extensions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-triggers-extensions-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/