From nobody Tue Oct 3 12:28:40 2017 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 2354F13303F; Tue, 3 Oct 2017 12:28:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aamelnikov@fastmail.fm, kevin.j.ma.ietf@gmail.com, cdni@ietf.org, cdni-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150705891909.30718.17029577970424668324.idtracker@ietfa.amsl.com> Date: Tue, 03 Oct 2017 12:28:39 -0700 Archived-At: Subject: [CDNi] cdni - Update to a Meeting Session Request for IETF 100 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 03 Oct 2017 19:28:39 -0000 An update to a meeting session request has just been submitted by Kevin J. Ma, a Chair of the cdni working group. --------------------------------------------------------- Working Group Name: Content Delivery Networks Interconnection Area Name: Applications and Real-Time Area Session Requester: Kevin Ma Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: tls dispatch alto acme webpush Second Priority: quic httpbis jsonbis kitten People who must be present: Francois Le Faucheur Alexey Melnikov Kevin J. Ma Phil Sorber Resources Requested: Special Requests: preferably not Friday --------------------------------------------------------- From alficles@gmail.com Wed Oct 4 14:42:40 2017 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 ED2E91344D6 for ; Wed, 4 Oct 2017 14:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LI9gEFyTl4Es for ; Wed, 4 Oct 2017 14:42:38 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5509D1321A2 for ; Wed, 4 Oct 2017 14:42:38 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id l68so11922800wmd.5 for ; Wed, 04 Oct 2017 14:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=K4dWvi2sPEM1MNaifvcZVsnUlLI4vlwf9XyG9LtCuhA=; b=hMKcih5DssJFAWlsWFA7LuacrJjQNVrKyAlRyt4GHgTnysAXDvJ/dbvV1B1PzyvOQJ vAn6x1X+P4iazs2jh4QNKUqvyCO+81/ZDavC1hE3MO3sCQmjPZlvwRE4RUmK3S29VdmW JxzBuRz8iCvBMyg0jZFbblUjX/uVdzWoFlw4sVcdJQKNgZD6wA5VYr5mh1xHTdp5nL8u 7V9c0qIW/bn6cOOginpsjNZy7HMvEP5udeaBOY8qpgsc30g1tcyC8z456XOa8twEISdR cxPHfODUNr7c7qX+QJLiiqrDO3hHPjenjG41A4Q4eKgYPdP1DLnquYWzj3X91F6xEHS7 vzeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=K4dWvi2sPEM1MNaifvcZVsnUlLI4vlwf9XyG9LtCuhA=; b=L7QrdIbS2OVkKFYzIU2KIf8lDLyEI2eXHMBnM4E0hxLzywskpx8iVk1hhgBUTskKD0 pPJ/bEidz8IN26O+wX3YhgOgb795WDNZ1I32Sx1AEXIWb8jJgGZsz6LSEmed2wbB8zh6 H+6Q/FDIq9sct1Nro9N8V2HWKprNhLoGw2a0hn1e9mxJYtKuHU/5UEQVz640o9xMzBfs iY8/t3CtKLkVWpNSQA5y8v0FxG0E+erj3Av+p7Vk8EIJdmeq5yFTxph9qT9lCyYwMCmw C5zLc+BzR/BYBRUs4jHaR72vKgjDLrKsXP4woIbyk7JK4bb5UkjSV6CpFMaXN23J9lRt U0HQ== X-Gm-Message-State: AMCzsaUvuK4HtWTYDyHOYmyQpo7uzIBlFAyEEM15IU7GJ4M+H5LYJ7fX CnlFTaskd/Tk5EV+onDS4VoS1VsxOEyJyX466i/e1Q== X-Google-Smtp-Source: AOwi7QCVvAxXVeq4IE0bMSJZz2Hr5c5UfqGsm4CMg7Gve81Uo+ByScRPin7CyraVC7aZAkCXOG0nbQRy9BP9bBQDeAo= X-Received: by 10.28.184.141 with SMTP id i135mr18408408wmf.143.1507153356130; Wed, 04 Oct 2017 14:42:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.185.106 with HTTP; Wed, 4 Oct 2017 14:42:35 -0700 (PDT) From: Chris Lemmons Date: Wed, 4 Oct 2017 15:42:35 -0600 Message-ID: To: cdni@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [CDNi] =?utf-8?q?URI_Signing_=E2=80=94_Feedback_from_an_Implement?= =?utf-8?q?er?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 04 Oct 2017 22:45:21 -0000 I recently implemented (most of) URI Signing as an Apache Traffic Server plugin. I used Draft 12 as my reference and I found a few rough edges that could be polished a bit. I apologize in advance for the wall of text, but I think it made more sense to collect my thoughts than it did to create a dozen emails. It's worth noting, I've only implemented it in a single-CDN context, so I haven't fully exercised some of the pieces. sub claim URIs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D According to RFC 7519 =C2=A7 4.1.2, the sub claim is of StringOrURI type, which specifies that while it may contain any value, if the value contains a colon, it must be a URI as specified in RFC 3986. But although all valid sub claims will contain a colon, very few are valid URIs. Even the example given doesn't appear to be a valid URI: uri-pattern:*://*/folder/content-83112371/quality_*/segment????.mp4 It contains several ?s and *s that would not be legal in a URI, as near as I can tell. Maybe I missed something in the URI spec, but this claim really doesn't feel like a URI to me. sub claim Simple Container =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The URI includes the query string and path parameters, which includes the JWT. The JWT cannot include a copy of itself. The only way this claim could match something is if it were presented as part of a token renewal via cookie. And that isn't terribly useful, since token renewal relies on regex/pattern matches to match future requests. And simply dropping the query string entirely isn't a great option, because the query string may contain other material that is important to match. And that doesn't help the path-parameter case either. As near as I can tell, there is no useful use-case for the simple container= . sub claim Hash Container =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This has the same problem as the simple container, just hashed in the middle. The JWT can't contain a hashed copy of itself for chicken-and-egg reasons. (Technically, proving that mathematically feels hard, since it might be possible to contrive a JWT that contains a hash that matches a signed copy of itself. That's sufficiently impractical to call impossible, though, I think.) sub claim Pattern Container =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Pattern Container is strictly less powerful than the regex container. And it uses a bespoke glob format that doesn't appear anywhere else, so each implementation will have to implement it from scratch. (This task isn't terribly hard, but it's really easy to accidentally do it exponentially and there are a few unobvious gotchas.) And in practice, I'm not sure how useful the globbing is. For the most part, unexpected query parameters are simply ignored. That means the example pattern: *://*/folder/content-83112371/quality_*/segment????.mp4 ... matches this URI: https://server.example.com/secret/file.xml?URISigningPackage=3DJWTGOESHERE&= hackery=3D/folder/content-83112371/quality_7/segmentcode.mp4 ... but not this URI: https://cdn.example.com/folder/content-83112371/quality_high/segment1234.mp= 4?URISigningPackage=3DJWTGOESHERE Given the widespread behaviour of handling query strings, few, if any, issuers would be able to meaningfully use the glob anywhere but in the last place. You definitely don't want people trying to use it like it is described in the examples. sub claim Regex Container =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This container is the most powerful of all the containers. Everything expressible in one of the other containers can be expressed here as well. The examples here are likely to lead people astray though. The example regex: .*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4 ... should probably be: [^:]*\\://[^/]*/folder/content-83112371/quality_[^/]*/segment.{3}\\.mp4(\?.= *)? Universal globs aren't terribly useful since they're very vulnerable to URL manipulation. The examples should use exclusionary patterns that end on the delimiting character. Also, the query is part of the pattern, so it needs to be part of the regex as well. The regex and pattern containers both don't specify that the patterns are anchored (no extra stuff is allowed on either end), but it seems implied and if it weren't anchored, it would be largely useless because of URI manipulation. The sub containers should probably specify that the pattern must match the entire URI. aud claim =3D=3D=3D=3D=3D=3D=3D According to RFC 7519 =C2=A7 4.1.3, the aud claim is either a StringOrURI or an array thereof. The draft describes what to do with a single string (which helpfully cannot contain a colon), but doesn't discuss the array case. I don't know that there's a strong reason to include the array format as legal, but I also don't know that there's a strong reason contrariwise. Either way, though, the draft should probably pick a side and document it. Additionally, that section specifies that: > If the principal processing the claim does not identify itself with a val= ue in the "aud" claim when this claim is present, then the JWT MUST be reje= cted. The interpretation of the value is generally application specific, but it would be very strange to say that the "principal processing the claim" (the CDN) identifies itself with the value in the aud claim (the Client's IP address). The aud claim seems to be designed to limit who will accept the token. It feels somewhat co-opted in this situation. cdniets default =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The cdniets field does not have a default value. It's legal for an issuer to elide this value even when providing a cdnistt of 1. It should either have a non-zero default value or be required when cdnistt is 1. Additionally, all other time values are real, this one is integer. The precision is probably not critical, but consistency is probably better. cdniets claim =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This should be added to the iat, not the exp. A crafty malefactor who wishes to share his url for all to use could simply repeatedly request the same small file more frequently than it expires. As specified in the draft, this would cause the exp to continuously extend. This could easily be used to create a "renewed" token that lasts for years. A CDN renewing a token should always add the the extension time to current time, instead, to get the expiration time. nbf leap seconds =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If issuers set nbf claims to the iat time, this will cause conforming implementations to incorrectly reject JWTs during leap seconds. This is an issue inherited from the JWT specification, but it's more serious in a token-renewal context, since it can cause a large number of streaming video clients to simultaneously stutter or disconnect. According to RFC 7419 and the POSIX specification it references, a leap second is required to "repeat" at the beginning of the next day. This will cause all issued tokens to be invalid for about a second. (If implementations "smear" the leap second in contravention of the POSIX spec, this will not be an issue, so long as the issuer and CDN are synchronized.) Since the issue is largely inherited from the JWT RFC, I don't know that it makes sense to attempt to fix it here. I just happened to run into it here. But a cautionary note that one should not set nbf to the current time might be valuable. key identification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When verifying a JWT, I need to know which key should be used to verify it. In my implementation, I use a combination of the iss claim and the kid in the JOSE header. But neither of those values are required. And as near as I can tell, the draft does not allow me to require them. It says I MAY use it to identify the key, but doesn't say I may reject an otherwise valid JWT that doesn't have an iss claim. Likewise, the JOSE kid header (RFC 7515 =C2=A7 4.1.4) is necessary to identify the specific key. As written, I don't believe I can deny an otherwise valid JWT for missing these fields. But the only way I can determine that it's valid is to try all the keys that could potentially be valid, which may be a very large number of keys (issuers can use many keys and a CDN may easily have multitudinous valid issuers). The CDN has a trust relationship with the issuers, so I can be sure that a signed JWT won't abuse my resources, but key identification by necessity must occur before verification. So, a malefactor who presents an invalidly signed JWT that lacks an iss claim and kid header can cause significant resource waste by forcing me to check all possible keys. A CDN should be able to reject a claim that doesn't present a valid issuer/kid combination. (It shouldn't be required to, of course, since it might only support a single key and it might be a non-issue.) A CDN that requires iss claims should probably be able to advertise it via the CDNI Metadata Interface as well. It might even be straightforward enough to say that if the CDNI Metadata Interface Property Issuers is not empty, the iss claim is required and if it's empty, it may be elided. That does limit some situations, though. URI attribute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The URI attribute can be encoded in either a query parameter or a path parameter. The draft implies, but does not clearly state, that a conforming implementation must accept a valid JWT in either location. This works, but could probably be a bit clearer. Also, any implementation that does what I'm given to understand is now called "Token Renewal" needs to accept JWTs via whatever mechanism they use as well. Specifically, the section on cdnistt=3D1 specifies that cookies should be used to send and receive the renewed token, but nothing seems to give the CDN permission to look anywhere but the query and path parameters for the JWT. In addition, the draft doesn't describe how the CDN should behave when it is given multiple cookies. In a token-renewal situation, this isn't hypothetical. A manifest signed with an expired JWT is quite likely to be presented with a valid recently-renewed cookie. renewal rules =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There isn't much said about the values in renewed tokens. Most of the rules that apply to CDNI redirection make sense for the exact same reasons for renewed tokens. Right now, a "renewed token" can contain different values for nearly anything. This should be fleshed out, I think, mostly by adding "or Signed Token Renewal" after "CDNI redirection" in most of the claims. jti claim =3D=3D=3D=3D=3D=3D I'm not entirely clear on how this would work in a CDN environment. The draft indicates that if it contains a nonce, the CDN can verify that it hasn't been used before. But that makes nonce-checking a synchronous event across the entire CDN. For every signed request, it would have to lock a global list of "used nonces", check it, add the new item or reject the JWT, the unlock. This feels slow, but different use cases might warrant it. This section also doesn't include either MUST or MAY language for a CDN that supports nonces. Instead, it just makes a statement about what a nonce might be useful for if a CDN did some probably slow things. I think this claim should be more specific about what a CDN MUST or MAY do if it wants to allow nonces to be used. From nobody Thu Oct 5 00:21:31 2017 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 873D6133070 for ; Thu, 5 Oct 2017 00:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3XPQZ2LpLG1s for ; Thu, 5 Oct 2017 00:19:59 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE5813247A for ; Thu, 5 Oct 2017 00:19:59 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id y44so2477810wry.10 for ; Thu, 05 Oct 2017 00:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6ZhpO6Jg2i2uOWlwHBBs5phsuGgNQh180rZsfSZpwRE=; b=QWQNktzkKg24MEY4Zjrc3PnyAY5Q7MEMdMeGCjp2ASuA3rWAkflrxEOy8KisfpD/tt j7ok0CYTj6y7c1wlCvCzosi7scUlqjr8Q7I3N0Sx+f25WRVUXggUi0rzTcrrucke9dYt W43f7y1dWAJ4N+lEAsVotiNW7iwNJHoYZ43gESQMeyv+TDvYIuqOqJ+wCg6uBWtp0/Vb XoPhAgsOE78jMIV+1x0yYjMm1N/P7GuuzwltpVDKZG1TM6XIUw8RdpWvrL8ykfd8lXCM BiTxD27vaLPYQQ06rutv2XUkoNQ2BfaTu1ZFLLFLmLHaXX+vM8E13EZdQA3UnQiGxYMp VrWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6ZhpO6Jg2i2uOWlwHBBs5phsuGgNQh180rZsfSZpwRE=; b=G7PZ+WEOk8bP6V0ePxPI4OTkOceBKiLWSMI3nrPn6/Jm1KbqIRFmW88fXz81W14+Sl 4mDEEw6SkfWVOPPMGyNz1uPOGXefSDhxbyieprCV9vMFxBNn7W6CQyKTrs4DBLPImytT +2ABQEXv+/KNvkQbJhaHr40iPxrn+SXbA5oxz5+u3yY3+icAWKd3M6qmx/mu8T/mvYAz jAsMhHBs4LPzeejlerkQiFMVaty2msEitLhrlTCNASFxlZzi9DzX1fStGPvyJVVQR7w2 xaTqGSvaxscNmXWjBfujJYehANTDGVODxZlL8E3y7FQIlq4lmBaUMBWn0TJBnKkNw7SZ B8pA== X-Gm-Message-State: AMCzsaVNTGITrZ8XVFhUJkF/dMDwdZeCoHtZs80+hercoWoX77LVGcs/ 2TzA6vY7cSN1jJyR1b8RKH8= X-Google-Smtp-Source: AOwi7QCqekx2FZn0SNuc3Kp7eeS6xbhfqSUYCbXZ0oyu8G/GfGVe7av9mR5HF5LbPPRF0bSkeSVeRg== X-Received: by 10.223.188.18 with SMTP id s18mr1788750wrg.118.1507187997519; Thu, 05 Oct 2017 00:19:57 -0700 (PDT) Received: from [192.168.1.21] ([78.113.216.125]) by smtp.gmail.com with ESMTPSA id b11sm4498622wrd.91.2017.10.05.00.19.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 00:19:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Francois Le Faucheur In-Reply-To: Date: Thu, 5 Oct 2017 09:19:50 +0200 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <1EA1FA59-DAE0-4377-A93A-DFA0DB93C46D@gmail.com> References: To: Chris Lemmons X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [CDNi] =?utf-8?q?URI_Signing_=E2=80=94_Feedback_from_an_Implemen?= =?utf-8?q?ter?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 05 Oct 2017 07:20:04 -0000 Thank you Chris. Such implementation feedback is very useful. Fran=C3=A7ois > On 4 Oct 2017, at 23:42, Chris Lemmons wrote: >=20 > I recently implemented (most of) URI Signing as an Apache Traffic > Server plugin. I used Draft 12 as my reference and I found a few rough > edges that could be polished a bit. I apologize in advance for the > wall of text, but I think it made more sense to collect my thoughts > than it did to create a dozen emails. It's worth noting, I've only > implemented it in a single-CDN context, so I haven't fully exercised > some of the pieces. >=20 >=20 >=20 > sub claim URIs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > According to RFC 7519 =C2=A7 4.1.2, the sub claim is of StringOrURI = type, > which specifies that while it may contain any value, if the value > contains a colon, it must be a URI as specified in RFC 3986. But > although all valid sub claims will contain a colon, very few are valid > URIs. Even the example given doesn't appear to be a valid URI: >=20 > uri-pattern:*://*/folder/content-83112371/quality_*/segment????.mp4 >=20 > It contains several ?s and *s that would not be legal in a URI, as > near as I can tell. Maybe I missed something in the URI spec, but this > claim really doesn't feel like a URI to me. >=20 >=20 >=20 > sub claim Simple Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The URI includes the query string and path parameters, which includes > the JWT. The JWT cannot include a copy of itself. The only way this > claim could match something is if it were presented as part of a token > renewal via cookie. And that isn't terribly useful, since token > renewal relies on regex/pattern matches to match future requests. >=20 > And simply dropping the query string entirely isn't a great option, > because the query string may contain other material that is important > to match. And that doesn't help the path-parameter case either. >=20 > As near as I can tell, there is no useful use-case for the simple = container. >=20 >=20 >=20 > sub claim Hash Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This has the same problem as the simple container, just hashed in the > middle. The JWT can't contain a hashed copy of itself for > chicken-and-egg reasons. (Technically, proving that mathematically > feels hard, since it might be possible to contrive a JWT that contains > a hash that matches a signed copy of itself. That's sufficiently > impractical to call impossible, though, I think.) >=20 >=20 >=20 > sub claim Pattern Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The Pattern Container is strictly less powerful than the regex > container. And it uses a bespoke glob format that doesn't appear > anywhere else, so each implementation will have to implement it from > scratch. (This task isn't terribly hard, but it's really easy to > accidentally do it exponentially and there are a few unobvious > gotchas.) >=20 > And in practice, I'm not sure how useful the globbing is. For the most > part, unexpected query parameters are simply ignored. That means the > example pattern: >=20 > *://*/folder/content-83112371/quality_*/segment????.mp4 >=20 > ... matches this URI: >=20 > = https://server.example.com/secret/file.xml?URISigningPackage=3DJWTGOESHERE= &hackery=3D/folder/content-83112371/quality_7/segmentcode.mp4 >=20 > ... but not this URI: >=20 > = https://cdn.example.com/folder/content-83112371/quality_high/segment1234.m= p4?URISigningPackage=3DJWTGOESHERE >=20 > Given the widespread behaviour of handling query strings, few, if any, > issuers would be able to meaningfully use the glob anywhere but in the > last place. You definitely don't want people trying to use it like it > is described in the examples. >=20 >=20 >=20 > sub claim Regex Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This container is the most powerful of all the containers. Everything > expressible in one of the other containers can be expressed here as > well. The examples here are likely to lead people astray though. The > example regex: >=20 > .*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4 >=20 > ... should probably be: >=20 > = [^:]*\\://[^/]*/folder/content-83112371/quality_[^/]*/segment.{3}\\.mp4(\?= .*)? >=20 > Universal globs aren't terribly useful since they're very vulnerable > to URL manipulation. The examples should use exclusionary patterns > that end on the delimiting character. Also, the query is part of the > pattern, so it needs to be part of the regex as well. >=20 > The regex and pattern containers both don't specify that the patterns > are anchored (no extra stuff is allowed on either end), but it seems > implied and if it weren't anchored, it would be largely useless > because of URI manipulation. The sub containers should probably > specify that the pattern must match the entire URI. >=20 >=20 >=20 > aud claim > =3D=3D=3D=3D=3D=3D=3D > According to RFC 7519 =C2=A7 4.1.3, the aud claim is either a = StringOrURI > or an array thereof. The draft describes what to do with a single > string (which helpfully cannot contain a colon), but doesn't discuss > the array case. I don't know that there's a strong reason to include > the array format as legal, but I also don't know that there's a strong > reason contrariwise. Either way, though, the draft should probably > pick a side and document it. >=20 > Additionally, that section specifies that: >=20 >> If the principal processing the claim does not identify itself with a = value in the "aud" claim when this claim is present, then the JWT MUST = be rejected. >=20 > The interpretation of the value is generally application specific, but > it would be very strange to say that the "principal processing the > claim" (the CDN) identifies itself with the value in the aud claim > (the Client's IP address). >=20 > The aud claim seems to be designed to limit who will accept the token. > It feels somewhat co-opted in this situation. >=20 >=20 >=20 > cdniets default > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The cdniets field does not have a default value. It's legal for an > issuer to elide this value even when providing a cdnistt of 1. It > should either have a non-zero default value or be required when > cdnistt is 1. >=20 > Additionally, all other time values are real, this one is integer. The > precision is probably not critical, but consistency is probably > better. >=20 >=20 >=20 > cdniets claim > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This should be added to the iat, not the exp. A crafty malefactor who > wishes to share his url for all to use could simply repeatedly request > the same small file more frequently than it expires. As specified in > the draft, this would cause the exp to continuously extend. This could > easily be used to create a "renewed" token that lasts for years. >=20 > A CDN renewing a token should always add the the extension time to > current time, instead, to get the expiration time. >=20 >=20 >=20 > nbf leap seconds > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If issuers set nbf claims to the iat time, this will cause conforming > implementations to incorrectly reject JWTs during leap seconds. This > is an issue inherited from the JWT specification, but it's more > serious in a token-renewal context, since it can cause a large number > of streaming video clients to simultaneously stutter or disconnect. >=20 > According to RFC 7419 and the POSIX specification it references, a > leap second is required to "repeat" at the beginning of the next day. > This will cause all issued tokens to be invalid for about a second. > (If implementations "smear" the leap second in contravention of the > POSIX spec, this will not be an issue, so long as the issuer and CDN > are synchronized.) >=20 > Since the issue is largely inherited from the JWT RFC, I don't know > that it makes sense to attempt to fix it here. I just happened to run > into it here. But a cautionary note that one should not set nbf to the > current time might be valuable. >=20 >=20 >=20 > key identification > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > When verifying a JWT, I need to know which key should be used to > verify it. In my implementation, I use a combination of the iss claim > and the kid in the JOSE header. But neither of those values are > required. And as near as I can tell, the draft does not allow me to > require them. It says I MAY use it to identify the key, but doesn't > say I may reject an otherwise valid JWT that doesn't have an iss > claim. >=20 > Likewise, the JOSE kid header (RFC 7515 =C2=A7 4.1.4) is necessary to > identify the specific key. >=20 > As written, I don't believe I can deny an otherwise valid JWT for > missing these fields. But the only way I can determine that it's valid > is to try all the keys that could potentially be valid, which may be a > very large number of keys (issuers can use many keys and a CDN may > easily have multitudinous valid issuers). The CDN has a trust > relationship with the issuers, so I can be sure that a signed JWT > won't abuse my resources, but key identification by necessity must > occur before verification. So, a malefactor who presents an invalidly > signed JWT that lacks an iss claim and kid header can cause > significant resource waste by forcing me to check all possible keys. >=20 > A CDN should be able to reject a claim that doesn't present a valid > issuer/kid combination. (It shouldn't be required to, of course, since > it might only support a single key and it might be a non-issue.) >=20 > A CDN that requires iss claims should probably be able to advertise it > via the CDNI Metadata Interface as well. It might even be > straightforward enough to say that if the CDNI Metadata Interface > Property Issuers is not empty, the iss claim is required and if it's > empty, it may be elided. That does limit some situations, though. >=20 >=20 >=20 > URI attribute > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The URI attribute can be encoded in either a query parameter or a path > parameter. The draft implies, but does not clearly state, that a > conforming implementation must accept a valid JWT in either location. > This works, but could probably be a bit clearer. Also, any > implementation that does what I'm given to understand is now called > "Token Renewal" needs to accept JWTs via whatever mechanism they use > as well. Specifically, the section on cdnistt=3D1 specifies that = cookies > should be used to send and receive the renewed token, but nothing > seems to give the CDN permission to look anywhere but the query and > path parameters for the JWT. >=20 > In addition, the draft doesn't describe how the CDN should behave when > it is given multiple cookies. In a token-renewal situation, this isn't > hypothetical. A manifest signed with an expired JWT is quite likely to > be presented with a valid recently-renewed cookie. >=20 >=20 >=20 > renewal rules > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > There isn't much said about the values in renewed tokens. Most of the > rules that apply to CDNI redirection make sense for the exact same > reasons for renewed tokens. Right now, a "renewed token" can contain > different values for nearly anything. This should be fleshed out, I > think, mostly by adding "or Signed Token Renewal" after "CDNI > redirection" in most of the claims. >=20 >=20 >=20 > jti claim > =3D=3D=3D=3D=3D=3D > I'm not entirely clear on how this would work in a CDN environment. > The draft indicates that if it contains a nonce, the CDN can verify > that it hasn't been used before. But that makes nonce-checking a > synchronous event across the entire CDN. For every signed request, it > would have to lock a global list of "used nonces", check it, add the > new item or reject the JWT, the unlock. This feels slow, but different > use cases might warrant it. >=20 > This section also doesn't include either MUST or MAY language for a > CDN that supports nonces. Instead, it just makes a statement about > what a nonce might be useful for if a CDN did some probably slow > things. I think this claim should be more specific about what a CDN > MUST or MAY do if it wants to allow nonces to be used. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Oct 9 03:09:54 2017 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 4126513493E for ; Sun, 8 Oct 2017 13:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 kxHWzCRE-mOO for ; Sun, 8 Oct 2017 13:12:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03ADB1241F3 for ; Sun, 8 Oct 2017 13:12:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D4FAFB81857; Sun, 8 Oct 2017 13:12:15 -0700 (PDT) To: ben.niven-jenkins@nokia.com, rob.murray@nokia.com, mcaulfie@cisco.com, kevin.j.ma@ericsson.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, flefauch@gmail.com, kevin.j.ma.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kevin.j.ma.ietf@gmail.com, cdni@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171008201215.D4FAFB81857@rfc-editor.org> Date: Sun, 8 Oct 2017 13:12:15 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 09 Oct 2017 03:09:52 -0700 Subject: [CDNi] [Technical Errata Reported] RFC8006 (5150) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 08 Oct 2017 20:12:27 -0000 The following errata report has been submitted for RFC8006, "Content Delivery Network Interconnection (CDNI) Metadata". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5150 -------------------------------------- Type: Technical Reported by: Kevin J. Ma Section: 6.10 Original Text ------------- "generic-metadata-type": "MI.SourceMetadata", "generic-metadata-value": { "sources": [ { "endpoint": ["acq1.ucdn.example"], "protocol": "http/1.1" }, { "endpoint": ["acq2.ucdn.example"], "protocol": "http/1.1" } ] } Corrected Text -------------- "generic-metadata-type": "MI.SourceMetadata", "generic-metadata-value": { "sources": [ { "endpoints": ["acq1.ucdn.example"], "protocol": "http/1.1" }, { "endpoints": ["acq2.ucdn.example"], "protocol": "http/1.1" } ] } Notes ----- The SourceMetadata object contains an array of "sources", which in turn contains an array of "endpoints". The example in section 6.10 uses the singular "endpoint" instead of the plural "endpoints". The examples in sections 4.2.1 and 4.2.1.1 correctly use the plural "endpoints" for the property name, as defined in section 4.2.1.1. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8006 (draft-ietf-cdni-metadata-21) -------------------------------------- Title : Content Delivery Network Interconnection (CDNI) Metadata Publication Date : December 2016 Author(s) : B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma Category : PROPOSED STANDARD Source : Content Delivery Networks Interconnection Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Wed Oct 18 07:31:05 2017 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 25F571321BB; Wed, 18 Oct 2017 07:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 0xCWRU8RxUFF; Wed, 18 Oct 2017 07:30:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28C813219B; Wed, 18 Oct 2017 07:30:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B16F6B8178D; Wed, 18 Oct 2017 07:30:35 -0700 (PDT) To: kevin.j.ma.ietf@gmail.com, ben.niven-jenkins@nokia.com, rob.murray@nokia.com, mcaulfie@cisco.com, kevin.j.ma@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aamelnikov@fastmail.fm, iesg@ietf.org, cdni@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171018143035.B16F6B8178D@rfc-editor.org> Date: Wed, 18 Oct 2017 07:30:35 -0700 (PDT) Archived-At: Subject: [CDNi] [Errata Verified] RFC8006 (5150) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 18 Oct 2017 14:30:59 -0000 The following errata report has been verified for RFC8006, "Content Delivery Network Interconnection (CDNI) Metadata". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5150 -------------------------------------- Status: Verified Type: Technical Reported by: Kevin J. Ma Date Reported: 2017-10-08 Verified by: Alexey Melnikov (IESG) Section: 6.10 Original Text ------------- "generic-metadata-type": "MI.SourceMetadata", "generic-metadata-value": { "sources": [ { "endpoint": ["acq1.ucdn.example"], "protocol": "http/1.1" }, { "endpoint": ["acq2.ucdn.example"], "protocol": "http/1.1" } ] } Corrected Text -------------- "generic-metadata-type": "MI.SourceMetadata", "generic-metadata-value": { "sources": [ { "endpoints": ["acq1.ucdn.example"], "protocol": "http/1.1" }, { "endpoints": ["acq2.ucdn.example"], "protocol": "http/1.1" } ] } Notes ----- The SourceMetadata object contains an array of "sources", which in turn contains an array of "endpoints". The example in section 6.10 uses the singular "endpoint" instead of the plural "endpoints". The examples in sections 4.2.1 and 4.2.1.1 correctly use the plural "endpoints" for the property name, as defined in section 4.2.1.1. -------------------------------------- RFC8006 (draft-ietf-cdni-metadata-21) -------------------------------------- Title : Content Delivery Network Interconnection (CDNI) Metadata Publication Date : December 2016 Author(s) : B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma Category : PROPOSED STANDARD Source : Content Delivery Networks Interconnection Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Fri Oct 20 17:29:30 2017 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 85261134531; Fri, 20 Oct 2017 17:24:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: cdni@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546553.20809.1219838340159723994.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:25 -0700 Archived-At: Subject: [CDNi] cdni - Requested session has been scheduled for IETF 100 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 21 Oct 2017 00:24:25 -0000 Dear Kevin Ma, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cdni Session 1 (1:00:00) Thursday, Afternoon Session III 1810-1910 Room Name: Sophia size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Content Delivery Networks Interconnection Area Name: Applications and Real-Time Area Session Requester: Kevin Ma Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: tls dispatch alto acme webpush Second Priority: quic httpbis jsonbis kitten People who must be present: Kevin J. Ma Alexey Melnikov Francois Le Faucheur Phil Sorber Resources Requested: Special Requests: preferably not Friday --------------------------------------------------------- From nobody Sun Oct 22 20:01:09 2017 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 E313913CE4D for ; Sun, 22 Oct 2017 20:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RjjSH_t6etNt for ; Sun, 22 Oct 2017 20:01:05 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455F513CE48 for ; Sun, 22 Oct 2017 20:01:05 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id p184so18449415lfe.12 for ; Sun, 22 Oct 2017 20:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VyqrF+768k488vMLQfzjz6yu/4y/ksPePVdcTvve018=; b=HKb+GU6lDY3SLbyV5zrqPJ2F98TsMDs9324ATqMG1jFDJPlrW48ZQbBhhs1wGle4cK RAQ41Mz9KDF/YWUEsvVD+wxWAm4b7lMV4DBWVcB108ktCs7PXO9QLLIB/Rx1H7HLi/Bh JCAMzYY0Zji4Xlg6CPAcQt7D+qx/ANbq0D11SADsZfM/XRjf7fZULp8jOqr0HCeTzMI9 qrph+YwjLD9HZlASZXt0i/Aa9UspYWPRA3thJ/uM+DDSHZLGrjR1sUYYMRpb5ogCTLWa Mpe4phwTXJ3evINupQyJPqTOkPxabjd6q/FWczU6pIZPtoFHrcbHrMemeoc0UG1JbU6Z xbmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VyqrF+768k488vMLQfzjz6yu/4y/ksPePVdcTvve018=; b=E+8LpNlcM/MocLt3sbIPF9SbYd2GgMvmTAoth3lxbP6hHGKHl+W2Rm2kH7JLcE2CzR pcxdJkHPXdKfzQEVce9+VskV4inJh0tcB87JHaOv3Ybfv3hduiadiFvuhTc+F+neASSh OvvC7EJn6SvMWlEJz0jeUgJJT8jS0+fsYhDmG9p8Me3F1Dui8l8VhqwnA/4SLv8Q0Ch1 3bJKb58vrSAc8wway7zrtYQzYTFp1oR0Lk8/gBsO8bXylmb5CWIcSHLWhFZ99+FSi2MM uwS3PE6xt6D3wJdP1UYZOiwIuOi/CGHH2mMt9jocqcYPoFws8hjNijwyt9O+KvobolUo 69yA== X-Gm-Message-State: AMCzsaU17EHIoXmCrVhlHW6pk4aBASWg/SwK+Mb/L3VnPRr2wYshwpLD o0OP22D2pUAgFYs9ShBLTrqyPqeikZ8zvQgWEUQ= X-Google-Smtp-Source: ABhQp+R2sBnqo0Fm9W+DJr7oGEgxG24oQyyG0RRAWOYiovCuiAyiU2JJCKN+a8y1Jm+2WzYoEYY5vXAzTQaxGIw2QYE= X-Received: by 10.46.43.145 with SMTP id r17mr4606530ljr.56.1508727663299; Sun, 22 Oct 2017 20:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.229.9 with HTTP; Sun, 22 Oct 2017 20:01:02 -0700 (PDT) From: Kevin Ma Date: Sun, 22 Oct 2017 23:01:02 -0400 Message-ID: To: cdni@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1c00a66f1246055c2e080d" Archived-At: Subject: [CDNi] IETF 100 CDNI Session: Thursday 1810-1910 in Sophia X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 23 Oct 2017 03:01:07 -0000 --94eb2c1c00a66f1246055c2e080d Content-Type: text/plain; charset="UTF-8" Hi All, The IETF 100 Agenda is out, and we will be meeting on Thursday evening. This is a friendly reminder that the draft deadline is only a week away; don't miss it. Please email the chairs if you would like a presentation slot in Singapore; the draft working group agenda deadline is also only a week away... thanx! -- Kevin and Francois. --94eb2c1c00a66f1246055c2e080d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

=C2=A0 The IETF 100 Agenda is o= ut, and we will be meeting on Thursday evening.

= =C2=A0 This is a friendly reminder that the draft deadline is only a week a= way; don't miss it.

=C2=A0 Please email the ch= airs if you would like a presentation slot in Singapore; the draft working = group agenda deadline is also only a week away...

= thanx!

--=C2=A0 Kevin and Francois.

=

--94eb2c1c00a66f1246055c2e080d-- From nobody Wed Oct 25 11:14:11 2017 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 BA7FD138103 for ; Wed, 25 Oct 2017 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 NVV-mWhvmwZS for ; Wed, 25 Oct 2017 11:14:08 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D57D137DCC for ; Wed, 25 Oct 2017 11:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3812; q=dns/txt; s=iport; t=1508955248; x=1510164848; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aeXAsGtqcF/UTr+iTti/v5UY68j9e3F0JzRhb6YXL9k=; b=K4jHWp6Jf6j9tC/sJTUES9mjL0ZJ31XPfgmMeMSpSLtkNlcX28XFvilc W6y1YBl3y2j9m6T0eXT/7SC4ZeIfpW5zq8mRkXCdwCml9QqZLM6I5aC5y hE3OSIqA84xatT3w1dbmw0eRCLC6VRtnWgvkcNWuPOwfFLG+tWnHRVjjs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClAAC20/BZ/5FdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9wZG4nB44SjwuBepB4hUIQggEKhTsChG0/GAECAQEBAQEBAWs?= =?us-ascii?q?dC4UdAQEBBC1cAgEIBA0EAQEvMh0IAQEEEwiJNGSsEYp2AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYMuggeBUIUTgSODLwESAYYUBaFzApRsgh6Fe4sWcJRkAhEZAYE?= =?us-ascii?q?4AR84gQNYehWDLYRfdolVgSSBEQEBAQ?= X-IronPort-AV: E=Sophos; i="5.43,432,1503360000"; d="scan'208,217"; a="21499093" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2017 18:14:07 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v9PIE76b017025 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Oct 2017 18:14:07 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 25 Oct 2017 14:14:06 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Wed, 25 Oct 2017 14:14:06 -0400 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: Request Interface Thread-Index: Ac4g9m0RVm2tap6FQ5Czkjw485w/f4pZjP7g Date: Wed, 25 Oct 2017 18:14:06 +0000 Message-ID: <056d427383a444529a57419dbda2c17a@XCH-RTP-006.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.86.152] Content-Type: multipart/alternative; boundary="_000_056d427383a444529a57419dbda2c17aXCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] Request Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 25 Oct 2017 18:14:10 -0000 --_000_056d427383a444529a57419dbda2c17aXCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, PC refresh triggered an old email. Please ignore. From: Kent Leung (kleung) Sent: Wednesday, October 25, 2017 11:00 AM To: cdni@ietf.org Subject: Request Interface For URI Signing perspective, the Request Interface is not in scope of the W= G. AI: need to include Request Interface section. Kent --_000_056d427383a444529a57419dbda2c17aXCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, PC refresh trig= gered an old email. Please ignore.

 

 

From: Kent Leung (kleung)
Sent: Wednesday, October 25, 2017 11:00 AM
To: cdni@ietf.org
Subject: Request Interface

 

For URI Signing perspective, the Request Interface i= s not in scope of the WG.

 

AI: need to include Request Interface section.<= /o:p>

 

Kent

--_000_056d427383a444529a57419dbda2c17aXCHRTP006ciscocom_-- From nobody Fri Oct 27 15:56:11 2017 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 1B7BE139394 for ; Fri, 27 Oct 2017 15:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 kc7s8nfYeyO4 for ; Fri, 27 Oct 2017 15:56:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7616013F602 for ; Fri, 27 Oct 2017 15:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20876; q=dns/txt; s=iport; t=1509144966; x=1510354566; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+/PTEwsQebsIbDJCy+uECkHPiEVtAjP/HqpUs2sc+qk=; b=FMZb7o0FeaoQArtqli4+jn72Lhzpo1e+ZBnO/A73CbMwRI4sop05IMyw N0q+Q9RArb2E3Odp+s+DMq8Dx4ULaH63vav/g0H7hG/qH7iVOHNK1fvLo r9DYb+4bvQJb0+OvEHEWmYjYC15sCX1i1sYgT1+EnGAq+8L1U8g6G4GLD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAQDzuPNZ/40NJK1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNfZG4nB4NzmTKBephTChgPhRQCGoQxQhUBAgEBAQEBAQFrKIU?= =?us-ascii?q?dAQEBAQIBAQEhETMHBAwHBAIBBgIOAwQBAQMCIwMCAgIlCxQBBQMIAgQBEgiKE?= =?us-ascii?q?wgQixKdZ4IniwYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgh+BNVKBUG18gh0?= =?us-ascii?q?BgQyDMoEoBRCDK4JhBYodHYkNhTuJAQKHZI0NkzaCUIoPiQQCERkBgTgBNSKBa?= =?us-ascii?q?HoVSYJkglsBHIFndwEBiToBJQeBBYERAQEB?= X-IronPort-AV: E=Sophos;i="5.44,306,1505779200"; d="scan'208";a="316947213" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Oct 2017 22:56:05 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v9RMu432026316 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Oct 2017 22:56:05 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Oct 2017 18:56:04 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1320.000; Fri, 27 Oct 2017 18:56:04 -0400 From: "Kent Leung (kleung)" To: Chris Lemmons , "cdni@ietf.org" Thread-Topic: =?utf-8?B?W0NETmldIFVSSSBTaWduaW5nIOKAlCBGZWVkYmFjayBmcm9tIGFuIEltcGxl?= =?utf-8?Q?menter?= Thread-Index: AQHTPWJ5661J6fEmeUSqwHAr1Ez2xKL0/Ilg Date: Fri, 27 Oct 2017 22:56:03 +0000 Message-ID: <530871e72c32471d89ebebdbb99c059d@XCH-RTP-006.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.110.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] =?utf-8?q?URI_Signing_=E2=80=94_Feedback_from_an_Implemen?= =?utf-8?q?ter?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 27 Oct 2017 22:56:09 -0000 SGkgQ2hyaXMuIFRoYW5rcyBmb3IgdGhlIHJldmlldyBjb21tZW50cy4gUGxlbnR5IG9mIGl0ZW1z IHRvIHBhcnNlIHRocm91Z2gsIHNvIHNvcnJ5IGZvciB0aGUgZGVsYXkuIERlZmluaXRlbHksIGl0 J3MgdmFsdWFibGUgdG8gaGF2ZSBpbXBsZW1lbnRlcidzIGZlZWRiYWNrLiBTZWUgbXkgY29tbWVu dHMgYmVsb3cuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENETmkgW21h aWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpcyBMZW1tb25zDQpT ZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgNCwgMjAxNyAyOjQzIFBNDQpUbzogY2RuaUBpZXRmLm9y Zw0KU3ViamVjdDogW0NETmldIFVSSSBTaWduaW5nIOKAlCBGZWVkYmFjayBmcm9tIGFuIEltcGxl bWVudGVyDQoNCkkgcmVjZW50bHkgaW1wbGVtZW50ZWQgKG1vc3Qgb2YpIFVSSSBTaWduaW5nIGFz IGFuIEFwYWNoZSBUcmFmZmljIFNlcnZlciBwbHVnaW4uIEkgdXNlZCBEcmFmdCAxMiBhcyBteSBy ZWZlcmVuY2UgYW5kIEkgZm91bmQgYSBmZXcgcm91Z2ggZWRnZXMgdGhhdCBjb3VsZCBiZSBwb2xp c2hlZCBhIGJpdC4gSSBhcG9sb2dpemUgaW4gYWR2YW5jZSBmb3IgdGhlIHdhbGwgb2YgdGV4dCwg YnV0IEkgdGhpbmsgaXQgbWFkZSBtb3JlIHNlbnNlIHRvIGNvbGxlY3QgbXkgdGhvdWdodHMgdGhh biBpdCBkaWQgdG8gY3JlYXRlIGEgZG96ZW4gZW1haWxzLiBJdCdzIHdvcnRoIG5vdGluZywgSSd2 ZSBvbmx5IGltcGxlbWVudGVkIGl0IGluIGEgc2luZ2xlLUNETiBjb250ZXh0LCBzbyBJIGhhdmVu J3QgZnVsbHkgZXhlcmNpc2VkIHNvbWUgb2YgdGhlIHBpZWNlcy4NCg0KDQoNCnN1YiBjbGFpbSBV UklzDQo9PT09PT09PT09PT0NCkFjY29yZGluZyB0byBSRkMgNzUxOSDCpyA0LjEuMiwgdGhlIHN1 YiBjbGFpbSBpcyBvZiBTdHJpbmdPclVSSSB0eXBlLCB3aGljaCBzcGVjaWZpZXMgdGhhdCB3aGls ZSBpdCBtYXkgY29udGFpbiBhbnkgdmFsdWUsIGlmIHRoZSB2YWx1ZSBjb250YWlucyBhIGNvbG9u LCBpdCBtdXN0IGJlIGEgVVJJIGFzIHNwZWNpZmllZCBpbiBSRkMgMzk4Ni4gQnV0IGFsdGhvdWdo IGFsbCB2YWxpZCBzdWIgY2xhaW1zIHdpbGwgY29udGFpbiBhIGNvbG9uLCB2ZXJ5IGZldyBhcmUg dmFsaWQgVVJJcy4gRXZlbiB0aGUgZXhhbXBsZSBnaXZlbiBkb2Vzbid0IGFwcGVhciB0byBiZSBh IHZhbGlkIFVSSToNCg0KdXJpLXBhdHRlcm46KjovLyovZm9sZGVyL2NvbnRlbnQtODMxMTIzNzEv cXVhbGl0eV8qL3NlZ21lbnQ/Pz8/Lm1wNA0KDQpJdCBjb250YWlucyBzZXZlcmFsID9zIGFuZCAq cyB0aGF0IHdvdWxkIG5vdCBiZSBsZWdhbCBpbiBhIFVSSSwgYXMgbmVhciBhcyBJIGNhbiB0ZWxs LiBNYXliZSBJIG1pc3NlZCBzb21ldGhpbmcgaW4gdGhlIFVSSSBzcGVjLCBidXQgdGhpcyBjbGFp bSByZWFsbHkgZG9lc24ndCBmZWVsIGxpa2UgYSBVUkkgdG8gbWUuDQoNCktMPiBUaGUg4oCcP+KA nSBhbmQg4oCcKuKAnSBhcmUgc3BlY2lhbCBsaXRlcmFscyBpbiB0aGUgVVJJIHBhdHRlcm4gZm9y IG1hdGNoaW5nIHRvIGFuIHZhbGlkIFVSSS4gSSBtYXkgYmUgbWlzc2luZyB5b3VyIHBvaW50LiBC dXQgdGhlIG9iamVjdGl2ZSBvZiB1cmktcGF0dGVybiBpcyB0byBzcGVjaWZ5IHRoZSBwYXR0ZXJu IG1hdGNoIGZvcm1hdCBhbmQgbm90IHRoZSBleGFjdCBVUkkuIFRoZSBVUkkgQ29udGFpbmVyIGlz IG1lYW50IHRvIHJlcHJlc2VudCB0aGUgVVJJIGluIHRoZSBmb3JtcyBkZXNjcmliZWQgaW4gc2Vj dGlvbiAyLjEuMTEuDQoNCg0Kc3ViIGNsYWltIFNpbXBsZSBDb250YWluZXINCj09PT09PT09PT09 PT09PT09PT09PQ0KVGhlIFVSSSBpbmNsdWRlcyB0aGUgcXVlcnkgc3RyaW5nIGFuZCBwYXRoIHBh cmFtZXRlcnMsIHdoaWNoIGluY2x1ZGVzIHRoZSBKV1QuIFRoZSBKV1QgY2Fubm90IGluY2x1ZGUg YSBjb3B5IG9mIGl0c2VsZi4gVGhlIG9ubHkgd2F5IHRoaXMgY2xhaW0gY291bGQgbWF0Y2ggc29t ZXRoaW5nIGlzIGlmIGl0IHdlcmUgcHJlc2VudGVkIGFzIHBhcnQgb2YgYSB0b2tlbiByZW5ld2Fs IHZpYSBjb29raWUuIEFuZCB0aGF0IGlzbid0IHRlcnJpYmx5IHVzZWZ1bCwgc2luY2UgdG9rZW4g cmVuZXdhbCByZWxpZXMgb24gcmVnZXgvcGF0dGVybiBtYXRjaGVzIHRvIG1hdGNoIGZ1dHVyZSBy ZXF1ZXN0cy4NCg0KQW5kIHNpbXBseSBkcm9wcGluZyB0aGUgcXVlcnkgc3RyaW5nIGVudGlyZWx5 IGlzbid0IGEgZ3JlYXQgb3B0aW9uLCBiZWNhdXNlIHRoZSBxdWVyeSBzdHJpbmcgbWF5IGNvbnRh aW4gb3RoZXIgbWF0ZXJpYWwgdGhhdCBpcyBpbXBvcnRhbnQgdG8gbWF0Y2guIEFuZCB0aGF0IGRv ZXNuJ3QgaGVscCB0aGUgcGF0aC1wYXJhbWV0ZXIgY2FzZSBlaXRoZXIuDQoNCkFzIG5lYXIgYXMg SSBjYW4gdGVsbCwgdGhlcmUgaXMgbm8gdXNlZnVsIHVzZS1jYXNlIGZvciB0aGUgc2ltcGxlIGNv bnRhaW5lci4NCg0KS0w+IEkgYWdyZWUgdGhhdCBpZiB0aGUgSldUIGlzIGNhcnJpZWQgaW4gdGhl IHF1ZXJ5IHN0cmluZyBhbmQgcGF0aCBwYXJhbWV0ZXJzLCB0aGUgSldUIG5lZWRzIHRvIGJlIG9t aXR0ZWQgcGFydC4gRm9yIGNvbnNpc3RlbmN5LCB0aGUgZW50aXJlIFVSSSBleGNlcHQgdGhlIHBh cnQgY29udGFpbmluZyB0aGUgdmFsdWUgZm9yIFVSSVNpZ25QYWNrYWdlIGF0dHJpYnV0ZSBpcyB2 YWxpZGF0ZWQgYnkgbWF0Y2ggb3BlcmF0aW9uLiBUaGlzIHNob3VsZCBoYXBwZW4gcmVnYXJkbGVz cyBpZiBjb29raWVzLCBxdWVyeSBzdHJpbmcgYW5kIHBhdGgsIGV0Yy4gYXJlIHVzZWQuDQoNCg0K c3ViIGNsYWltIEhhc2ggQ29udGFpbmVyDQo9PT09PT09PT09PT09PT09PT09PQ0KVGhpcyBoYXMg dGhlIHNhbWUgcHJvYmxlbSBhcyB0aGUgc2ltcGxlIGNvbnRhaW5lciwganVzdCBoYXNoZWQgaW4g dGhlIG1pZGRsZS4gVGhlIEpXVCBjYW4ndCBjb250YWluIGEgaGFzaGVkIGNvcHkgb2YgaXRzZWxm IGZvciBjaGlja2VuLWFuZC1lZ2cgcmVhc29ucy4gKFRlY2huaWNhbGx5LCBwcm92aW5nIHRoYXQg bWF0aGVtYXRpY2FsbHkgZmVlbHMgaGFyZCwgc2luY2UgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8g Y29udHJpdmUgYSBKV1QgdGhhdCBjb250YWlucyBhIGhhc2ggdGhhdCBtYXRjaGVzIGEgc2lnbmVk IGNvcHkgb2YgaXRzZWxmLiBUaGF0J3Mgc3VmZmljaWVudGx5IGltcHJhY3RpY2FsIHRvIGNhbGwg aW1wb3NzaWJsZSwgdGhvdWdoLCBJIHRoaW5rLikNCg0KDQpLTD4gVGhpcyBzaG91bGQgYmUgdHJl YXRlZCB0aGUgc2FtZSBhcyBhYm92ZSwgYnkgZXhjbHVkaW5nIEpXVCB0byBhdm9pZCB0aGUgY2hp Y2tlbi1hbmQtZWdnIHNpdHVhdGlvbi4NCg0KDQpzdWIgY2xhaW0gUGF0dGVybiBDb250YWluZXIN Cj09PT09PT09PT09PT09PT09PT09PQ0KVGhlIFBhdHRlcm4gQ29udGFpbmVyIGlzIHN0cmljdGx5 IGxlc3MgcG93ZXJmdWwgdGhhbiB0aGUgcmVnZXggY29udGFpbmVyLiBBbmQgaXQgdXNlcyBhIGJl c3Bva2UgZ2xvYiBmb3JtYXQgdGhhdCBkb2Vzbid0IGFwcGVhciBhbnl3aGVyZSBlbHNlLCBzbyBl YWNoIGltcGxlbWVudGF0aW9uIHdpbGwgaGF2ZSB0byBpbXBsZW1lbnQgaXQgZnJvbSBzY3JhdGNo LiAoVGhpcyB0YXNrIGlzbid0IHRlcnJpYmx5IGhhcmQsIGJ1dCBpdCdzIHJlYWxseSBlYXN5IHRv IGFjY2lkZW50YWxseSBkbyBpdCBleHBvbmVudGlhbGx5IGFuZCB0aGVyZSBhcmUgYSBmZXcgdW5v YnZpb3VzDQpnb3RjaGFzLikNCg0KQW5kIGluIHByYWN0aWNlLCBJJ20gbm90IHN1cmUgaG93IHVz ZWZ1bCB0aGUgZ2xvYmJpbmcgaXMuIEZvciB0aGUgbW9zdCBwYXJ0LCB1bmV4cGVjdGVkIHF1ZXJ5 IHBhcmFtZXRlcnMgYXJlIHNpbXBseSBpZ25vcmVkLiBUaGF0IG1lYW5zIHRoZSBleGFtcGxlIHBh dHRlcm46DQoNCio6Ly8qL2ZvbGRlci9jb250ZW50LTgzMTEyMzcxL3F1YWxpdHlfKi9zZWdtZW50 Pz8/Py5tcDQNCg0KLi4uIG1hdGNoZXMgdGhpcyBVUkk6DQoNCmh0dHBzOi8vc2VydmVyLmV4YW1w bGUuY29tL3NlY3JldC9maWxlLnhtbD9VUklTaWduaW5nUGFja2FnZT1KV1RHT0VTSEVSRSZoYWNr ZXJ5PS9mb2xkZXIvY29udGVudC04MzExMjM3MS9xdWFsaXR5Xzcvc2VnbWVudGNvZGUubXA0DQoN Ci4uLiBidXQgbm90IHRoaXMgVVJJOg0KDQpodHRwczovL2Nkbi5leGFtcGxlLmNvbS9mb2xkZXIv Y29udGVudC04MzExMjM3MS9xdWFsaXR5X2hpZ2gvc2VnbWVudDEyMzQubXA0P1VSSVNpZ25pbmdQ YWNrYWdlPUpXVEdPRVNIRVJFDQoNCkdpdmVuIHRoZSB3aWRlc3ByZWFkIGJlaGF2aW91ciBvZiBo YW5kbGluZyBxdWVyeSBzdHJpbmdzLCBmZXcsIGlmIGFueSwgaXNzdWVycyB3b3VsZCBiZSBhYmxl IHRvIG1lYW5pbmdmdWxseSB1c2UgdGhlIGdsb2IgYW55d2hlcmUgYnV0IGluIHRoZSBsYXN0IHBs YWNlLiBZb3UgZGVmaW5pdGVseSBkb24ndCB3YW50IHBlb3BsZSB0cnlpbmcgdG8gdXNlIGl0IGxp a2UgaXQgaXMgZGVzY3JpYmVkIGluIHRoZSBleGFtcGxlcy4NCg0KDQpLTD4gSSBrbm93IHRoYXQg d2FzIFJheeKAmXMgcHJvcG9zYWwuIEkgc2Vuc2UgdGhlIGV4YW1wbGUgd2FzIHRhcmdldGVkIGZv ciBIQVMgY2FzZSB3aGVyZSB0aGlzIFVSSSB3YXMgZm9yIHRoZSB2aWRlbyBzZWdtZW50IHdoaWNo IHdvdWxkIHVzZSBzaWduZWQgdG9rZW4gY2hhaW4gd2l0aCBjb29raWUgdG8gY2FycnkgdGhlIEpX VC4gQnV0IHRoYXQncyBqdXN0IG15IGFzc3VtcHRpb24gYXMgdGhhdCB3b3VsZCBmaXQgd2l0aCB0 aGUgZXhhbXBsZS4gTWF5YmUgdGhlIG1hbmlmZXN0IGZpbGUgaXMgbGlrZWx5IHRvIGhhdmUgc2ln bmVkIFVSTCB3aXRob3V0IHVzaW5nIHNpZ25lZCB0b2tlbiBjaGFpbi4gRS5nLiwgaHR0cDovLyov Zm9sZGVyL2NvbnRlbnQtODMxMTIzNzEvbWFuaWZlc3QvKi54bWwoXD8uKikuDQoNCg0Kc3ViIGNs YWltIFJlZ2V4IENvbnRhaW5lcg0KPT09PT09PT09PT09PT09PT09PT09DQpUaGlzIGNvbnRhaW5l ciBpcyB0aGUgbW9zdCBwb3dlcmZ1bCBvZiBhbGwgdGhlIGNvbnRhaW5lcnMuIEV2ZXJ5dGhpbmcg ZXhwcmVzc2libGUgaW4gb25lIG9mIHRoZSBvdGhlciBjb250YWluZXJzIGNhbiBiZSBleHByZXNz ZWQgaGVyZSBhcyB3ZWxsLiBUaGUgZXhhbXBsZXMgaGVyZSBhcmUgbGlrZWx5IHRvIGxlYWQgcGVv cGxlIGFzdHJheSB0aG91Z2guIFRoZSBleGFtcGxlIHJlZ2V4Og0KDQouKlxcOi8vLiovZm9sZGVy L2NvbnRlbnQtODMxMTIzNzEvcXVhbGl0eV8uKi9zZWdtZW50LnszfVxcLm1wNA0KDQouLi4gc2hv dWxkIHByb2JhYmx5IGJlOg0KDQpbXjpdKlxcOi8vW14vXSovZm9sZGVyL2NvbnRlbnQtODMxMTIz NzEvcXVhbGl0eV9bXi9dKi9zZWdtZW50LnszfVxcLm1wNChcPy4qKT8NCg0KVW5pdmVyc2FsIGds b2JzIGFyZW4ndCB0ZXJyaWJseSB1c2VmdWwgc2luY2UgdGhleSdyZSB2ZXJ5IHZ1bG5lcmFibGUg dG8gVVJMIG1hbmlwdWxhdGlvbi4gVGhlIGV4YW1wbGVzIHNob3VsZCB1c2UgZXhjbHVzaW9uYXJ5 IHBhdHRlcm5zIHRoYXQgZW5kIG9uIHRoZSBkZWxpbWl0aW5nIGNoYXJhY3Rlci4gQWxzbywgdGhl IHF1ZXJ5IGlzIHBhcnQgb2YgdGhlIHBhdHRlcm4sIHNvIGl0IG5lZWRzIHRvIGJlIHBhcnQgb2Yg dGhlIHJlZ2V4IGFzIHdlbGwuDQoNClRoZSByZWdleCBhbmQgcGF0dGVybiBjb250YWluZXJzIGJv dGggZG9uJ3Qgc3BlY2lmeSB0aGF0IHRoZSBwYXR0ZXJucyBhcmUgYW5jaG9yZWQgKG5vIGV4dHJh IHN0dWZmIGlzIGFsbG93ZWQgb24gZWl0aGVyIGVuZCksIGJ1dCBpdCBzZWVtcyBpbXBsaWVkIGFu ZCBpZiBpdCB3ZXJlbid0IGFuY2hvcmVkLCBpdCB3b3VsZCBiZSBsYXJnZWx5IHVzZWxlc3MgYmVj YXVzZSBvZiBVUkkgbWFuaXB1bGF0aW9uLiBUaGUgc3ViIGNvbnRhaW5lcnMgc2hvdWxkIHByb2Jh Ymx5IHNwZWNpZnkgdGhhdCB0aGUgcGF0dGVybiBtdXN0IG1hdGNoIHRoZSBlbnRpcmUgVVJJLg0K DQpLTD4gSSdtIE9LIHdpdGggeW91ciBzdWdnZXN0ZWQgZXhhbXBsZSBzdHJpbmcuDQoNCg0KYXVk IGNsYWltDQo9PT09PT09DQpBY2NvcmRpbmcgdG8gUkZDIDc1MTkgwqcgNC4xLjMsIHRoZSBhdWQg Y2xhaW0gaXMgZWl0aGVyIGEgU3RyaW5nT3JVUkkgb3IgYW4gYXJyYXkgdGhlcmVvZi4gVGhlIGRy YWZ0IGRlc2NyaWJlcyB3aGF0IHRvIGRvIHdpdGggYSBzaW5nbGUgc3RyaW5nICh3aGljaCBoZWxw ZnVsbHkgY2Fubm90IGNvbnRhaW4gYSBjb2xvbiksIGJ1dCBkb2Vzbid0IGRpc2N1c3MgdGhlIGFy cmF5IGNhc2UuIEkgZG9uJ3Qga25vdyB0aGF0IHRoZXJlJ3MgYSBzdHJvbmcgcmVhc29uIHRvIGlu Y2x1ZGUgdGhlIGFycmF5IGZvcm1hdCBhcyBsZWdhbCwgYnV0IEkgYWxzbyBkb24ndCBrbm93IHRo YXQgdGhlcmUncyBhIHN0cm9uZyByZWFzb24gY29udHJhcml3aXNlLiBFaXRoZXIgd2F5LCB0aG91 Z2gsIHRoZSBkcmFmdCBzaG91bGQgcHJvYmFibHkgcGljayBhIHNpZGUgYW5kIGRvY3VtZW50IGl0 Lg0KDQpLTD4gU2luY2Ug4oCcYXVk4oCdIGlzIHVzZWQgZm9yIENsaWVudCBJUC9JUCBwcmVmaXgs IHRoZSBJUHY2IGFkZHJlc3MgaGFzIGNvbG9uLWJhc2VkIHJlcHJlc2VudGF0aW9uLiBUaGF0IG1h eSBiZSBhbiBpc3N1ZT8gSSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGFycmF5LiBUaG91Z2ggdGhl IGxhbmd1YWdlIGluIFJGQyA3NTE5IGNvdmVycyB0aGUgY2FzZSBvZiBhIHNpbmdsZSBTdHJpbmdP clVSSSBjYXNlIGFscmVhZHkgKOKAnEluIHRoZSBzcGVjaWFsIGNhc2Ugd2hlbiB0aGUgSldUIGhh cyBvbmUgYXVkaWVuY2UsIHRoZSAiYXVkIiB2YWx1ZSBNQVkgYmUgYSBzaW5nbGUgY2FzZS1zZW5z aXRpdmUgc3RyaW5nIGNvbnRhaW5pbmcgYSBTdHJpbmdPclVSSSB2YWx1ZS7igJwpDQoNCg0KQWRk aXRpb25hbGx5LCB0aGF0IHNlY3Rpb24gc3BlY2lmaWVzIHRoYXQ6DQoNCj4gSWYgdGhlIHByaW5j aXBhbCBwcm9jZXNzaW5nIHRoZSBjbGFpbSBkb2VzIG5vdCBpZGVudGlmeSBpdHNlbGYgd2l0aCBh IHZhbHVlIGluIHRoZSAiYXVkIiBjbGFpbSB3aGVuIHRoaXMgY2xhaW0gaXMgcHJlc2VudCwgdGhl biB0aGUgSldUIE1VU1QgYmUgcmVqZWN0ZWQuDQoNClRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUg dmFsdWUgaXMgZ2VuZXJhbGx5IGFwcGxpY2F0aW9uIHNwZWNpZmljLCBidXQgaXQgd291bGQgYmUg dmVyeSBzdHJhbmdlIHRvIHNheSB0aGF0IHRoZSAicHJpbmNpcGFsIHByb2Nlc3NpbmcgdGhlIGNs YWltIiAodGhlIENETikgaWRlbnRpZmllcyBpdHNlbGYgd2l0aCB0aGUgdmFsdWUgaW4gdGhlIGF1 ZCBjbGFpbSAodGhlIENsaWVudCdzIElQIGFkZHJlc3MpLg0KDQpUaGUgYXVkIGNsYWltIHNlZW1z IHRvIGJlIGRlc2lnbmVkIHRvIGxpbWl0IHdobyB3aWxsIGFjY2VwdCB0aGUgdG9rZW4uDQpJdCBm ZWVscyBzb21ld2hhdCBjby1vcHRlZCBpbiB0aGlzIHNpdHVhdGlvbi4NCg0KDQpLTD4gSSBnZXQg eW91ciBwb2ludC4gVGhlIGRyYWZ0IHVzZXMg4oCcYXVk4oCdIGFzIHRoZSBpbnRlbmRlZCByZWNl aXZlciAoaS5lLiBVQSBhcyBpZGVudGlmaWVkIGJ5IENsaWVudCBJUCkgb2YgdGhlIHJlcXVlc3Rl ZCBjb250ZW50LiBJdOKAmXMgYSBiaXQgY29udm9sdXRlZCBzaW5jZSBJIGJlbGlldmUgdGhhdCDi gJxhdWTigJ0gaW4gSldUIGlzIGZvciB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoZSB0b2tl biAoQ0ROKS4gUGVyaGFwcyB3ZSBzaG91bGQgaW50cm9kdWNlIGEgQ2xpZW50IElQIGNsYWltIGZv ciBDRE4gdG8gbWF0Y2ggdGhlIHNvdXJjZSBJUCBhZ2FpbnN0IHRoZSB2YWx1ZT8NCg0KDQpjZG5p ZXRzIGRlZmF1bHQNCj09PT09PT09PT09DQpUaGUgY2RuaWV0cyBmaWVsZCBkb2VzIG5vdCBoYXZl IGEgZGVmYXVsdCB2YWx1ZS4gSXQncyBsZWdhbCBmb3IgYW4gaXNzdWVyIHRvIGVsaWRlIHRoaXMg dmFsdWUgZXZlbiB3aGVuIHByb3ZpZGluZyBhIGNkbmlzdHQgb2YgMS4gSXQgc2hvdWxkIGVpdGhl ciBoYXZlIGEgbm9uLXplcm8gZGVmYXVsdCB2YWx1ZSBvciBiZSByZXF1aXJlZCB3aGVuIGNkbmlz dHQgaXMgMS4NCg0KQWRkaXRpb25hbGx5LCBhbGwgb3RoZXIgdGltZSB2YWx1ZXMgYXJlIHJlYWws IHRoaXMgb25lIGlzIGludGVnZXIuIFRoZSBwcmVjaXNpb24gaXMgcHJvYmFibHkgbm90IGNyaXRp Y2FsLCBidXQgY29uc2lzdGVuY3kgaXMgcHJvYmFibHkgYmV0dGVyLg0KDQoNCktMPiBJIHRoaW5r IGNkbmlldHMgc2hvdWxkIGJlIHJlcXVpcmVkIHdoZW4gY2RuaXN0dCBpcyAxLiBEcmFmdCBzaG91 bGQgYmUgZXhwbGljaXQuIEknbSBPSyB3aXRoIHVzaW5nIE51bWVyaWNEYXRlIChyZWFsKSB0eXBl IGZvciBjb25zaXN0ZW5jeS4gQnV0IHlvdXIgbmV4dCBwb2ludCBtYWtlcyBtZSB0aGluayBpdCdz IGJldHRlciB0byBiZSBhbiBpbnRlZ2VyIHRvIGluZGljYXRlIHRoZSB0aW1lIGRlbHRhIGFuZCBu b3QgYWJzb2x1dGUgdGltZSB0aGF0IGlzIHJlcXVlc3RlZC4gU28gY2RuaWV0cyBpcyBub3QgYSB0 aW1lIHZhbHVlLCBidXQgYSBwb3NpdGl2ZSBpbnRlZ2VyIHZhbHVlIHRoYXQgaXMgdXNlZCB0byBp bmNyZWFzZSB0aGUgZXhwaXJhdGlvbiB0aW1lIG9mIHRoZSBtYXRjaGVkIFVSSS4gV291bGQgdGhh dCBiZSBPSz8NCg0KDQpjZG5pZXRzIGNsYWltDQo9PT09PT09PT09DQpUaGlzIHNob3VsZCBiZSBh ZGRlZCB0byB0aGUgaWF0LCBub3QgdGhlIGV4cC4gQSBjcmFmdHkgbWFsZWZhY3RvciB3aG8gd2lz aGVzIHRvIHNoYXJlIGhpcyB1cmwgZm9yIGFsbCB0byB1c2UgY291bGQgc2ltcGx5IHJlcGVhdGVk bHkgcmVxdWVzdCB0aGUgc2FtZSBzbWFsbCBmaWxlIG1vcmUgZnJlcXVlbnRseSB0aGFuIGl0IGV4 cGlyZXMuIEFzIHNwZWNpZmllZCBpbiB0aGUgZHJhZnQsIHRoaXMgd291bGQgY2F1c2UgdGhlIGV4 cCB0byBjb250aW51b3VzbHkgZXh0ZW5kLiBUaGlzIGNvdWxkIGVhc2lseSBiZSB1c2VkIHRvIGNy ZWF0ZSBhICJyZW5ld2VkIiB0b2tlbiB0aGF0IGxhc3RzIGZvciB5ZWFycy4NCg0KQSBDRE4gcmVu ZXdpbmcgYSB0b2tlbiBzaG91bGQgYWx3YXlzIGFkZCB0aGUgdGhlIGV4dGVuc2lvbiB0aW1lIHRv IGN1cnJlbnQgdGltZSwgaW5zdGVhZCwgdG8gZ2V0IHRoZSBleHBpcmF0aW9uIHRpbWUuDQoNCktM PiBHb29kIHBvaW50LiBUaGUgY3VycmVudCB0aW1lIHNob3VsZCBiZSB1c2VkIGFzIHJlZmVyZW5j ZSBmb3IgaW5jcmVhc2luZyB0aGUgdGltZSBkZWx0YSBmb3IgZXhwaXJhdGlvbiB0byBwcmV2ZW50 IGFkZGl0aXZlIGV4dGVuc2lvbi4NCg0KDQpuYmYgbGVhcCBzZWNvbmRzDQo9PT09PT09PT09PT09 DQpJZiBpc3N1ZXJzIHNldCBuYmYgY2xhaW1zIHRvIHRoZSBpYXQgdGltZSwgdGhpcyB3aWxsIGNh dXNlIGNvbmZvcm1pbmcgaW1wbGVtZW50YXRpb25zIHRvIGluY29ycmVjdGx5IHJlamVjdCBKV1Rz IGR1cmluZyBsZWFwIHNlY29uZHMuIFRoaXMgaXMgYW4gaXNzdWUgaW5oZXJpdGVkIGZyb20gdGhl IEpXVCBzcGVjaWZpY2F0aW9uLCBidXQgaXQncyBtb3JlIHNlcmlvdXMgaW4gYSB0b2tlbi1yZW5l d2FsIGNvbnRleHQsIHNpbmNlIGl0IGNhbiBjYXVzZSBhIGxhcmdlIG51bWJlciBvZiBzdHJlYW1p bmcgdmlkZW8gY2xpZW50cyB0byBzaW11bHRhbmVvdXNseSBzdHV0dGVyIG9yIGRpc2Nvbm5lY3Qu DQoNCkFjY29yZGluZyB0byBSRkMgNzQxOSBhbmQgdGhlIFBPU0lYIHNwZWNpZmljYXRpb24gaXQg cmVmZXJlbmNlcywgYSBsZWFwIHNlY29uZCBpcyByZXF1aXJlZCB0byAicmVwZWF0IiBhdCB0aGUg YmVnaW5uaW5nIG9mIHRoZSBuZXh0IGRheS4NClRoaXMgd2lsbCBjYXVzZSBhbGwgaXNzdWVkIHRv a2VucyB0byBiZSBpbnZhbGlkIGZvciBhYm91dCBhIHNlY29uZC4NCihJZiBpbXBsZW1lbnRhdGlv bnMgInNtZWFyIiB0aGUgbGVhcCBzZWNvbmQgaW4gY29udHJhdmVudGlvbiBvZiB0aGUgUE9TSVgg c3BlYywgdGhpcyB3aWxsIG5vdCBiZSBhbiBpc3N1ZSwgc28gbG9uZyBhcyB0aGUgaXNzdWVyIGFu ZCBDRE4gYXJlIHN5bmNocm9uaXplZC4pDQoNClNpbmNlIHRoZSBpc3N1ZSBpcyBsYXJnZWx5IGlu aGVyaXRlZCBmcm9tIHRoZSBKV1QgUkZDLCBJIGRvbid0IGtub3cgdGhhdCBpdCBtYWtlcyBzZW5z ZSB0byBhdHRlbXB0IHRvIGZpeCBpdCBoZXJlLiBJIGp1c3QgaGFwcGVuZWQgdG8gcnVuIGludG8g aXQgaGVyZS4gQnV0IGEgY2F1dGlvbmFyeSBub3RlIHRoYXQgb25lIHNob3VsZCBub3Qgc2V0IG5i ZiB0byB0aGUgY3VycmVudCB0aW1lIG1pZ2h0IGJlIHZhbHVhYmxlLg0KDQoNCg0Ka2V5IGlkZW50 aWZpY2F0aW9uDQo9PT09PT09PT09PT09DQpXaGVuIHZlcmlmeWluZyBhIEpXVCwgSSBuZWVkIHRv IGtub3cgd2hpY2gga2V5IHNob3VsZCBiZSB1c2VkIHRvIHZlcmlmeSBpdC4gSW4gbXkgaW1wbGVt ZW50YXRpb24sIEkgdXNlIGEgY29tYmluYXRpb24gb2YgdGhlIGlzcyBjbGFpbSBhbmQgdGhlIGtp ZCBpbiB0aGUgSk9TRSBoZWFkZXIuIEJ1dCBuZWl0aGVyIG9mIHRob3NlIHZhbHVlcyBhcmUgcmVx dWlyZWQuIEFuZCBhcyBuZWFyIGFzIEkgY2FuIHRlbGwsIHRoZSBkcmFmdCBkb2VzIG5vdCBhbGxv dyBtZSB0byByZXF1aXJlIHRoZW0uIEl0IHNheXMgSSBNQVkgdXNlIGl0IHRvIGlkZW50aWZ5IHRo ZSBrZXksIGJ1dCBkb2Vzbid0IHNheSBJIG1heSByZWplY3QgYW4gb3RoZXJ3aXNlIHZhbGlkIEpX VCB0aGF0IGRvZXNuJ3QgaGF2ZSBhbiBpc3MgY2xhaW0uDQoNCkxpa2V3aXNlLCB0aGUgSk9TRSBr aWQgaGVhZGVyIChSRkMgNzUxNSDCpyA0LjEuNCkgaXMgbmVjZXNzYXJ5IHRvIGlkZW50aWZ5IHRo ZSBzcGVjaWZpYyBrZXkuDQoNCkFzIHdyaXR0ZW4sIEkgZG9uJ3QgYmVsaWV2ZSBJIGNhbiBkZW55 IGFuIG90aGVyd2lzZSB2YWxpZCBKV1QgZm9yIG1pc3NpbmcgdGhlc2UgZmllbGRzLiBCdXQgdGhl IG9ubHkgd2F5IEkgY2FuIGRldGVybWluZSB0aGF0IGl0J3MgdmFsaWQgaXMgdG8gdHJ5IGFsbCB0 aGUga2V5cyB0aGF0IGNvdWxkIHBvdGVudGlhbGx5IGJlIHZhbGlkLCB3aGljaCBtYXkgYmUgYSB2 ZXJ5IGxhcmdlIG51bWJlciBvZiBrZXlzIChpc3N1ZXJzIGNhbiB1c2UgbWFueSBrZXlzIGFuZCBh IENETiBtYXkgZWFzaWx5IGhhdmUgbXVsdGl0dWRpbm91cyB2YWxpZCBpc3N1ZXJzKS4gVGhlIENE TiBoYXMgYSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aCB0aGUgaXNzdWVycywgc28gSSBjYW4gYmUg c3VyZSB0aGF0IGEgc2lnbmVkIEpXVCB3b24ndCBhYnVzZSBteSByZXNvdXJjZXMsIGJ1dCBrZXkg aWRlbnRpZmljYXRpb24gYnkgbmVjZXNzaXR5IG11c3Qgb2NjdXIgYmVmb3JlIHZlcmlmaWNhdGlv bi4gU28sIGEgbWFsZWZhY3RvciB3aG8gcHJlc2VudHMgYW4gaW52YWxpZGx5IHNpZ25lZCBKV1Qg dGhhdCBsYWNrcyBhbiBpc3MgY2xhaW0gYW5kIGtpZCBoZWFkZXIgY2FuIGNhdXNlIHNpZ25pZmlj YW50IHJlc291cmNlIHdhc3RlIGJ5IGZvcmNpbmcgbWUgdG8gY2hlY2sgYWxsIHBvc3NpYmxlIGtl eXMuDQoNCkEgQ0ROIHNob3VsZCBiZSBhYmxlIHRvIHJlamVjdCBhIGNsYWltIHRoYXQgZG9lc24n dCBwcmVzZW50IGEgdmFsaWQgaXNzdWVyL2tpZCBjb21iaW5hdGlvbi4gKEl0IHNob3VsZG4ndCBi ZSByZXF1aXJlZCB0bywgb2YgY291cnNlLCBzaW5jZSBpdCBtaWdodCBvbmx5IHN1cHBvcnQgYSBz aW5nbGUga2V5IGFuZCBpdCBtaWdodCBiZSBhIG5vbi1pc3N1ZS4pDQoNCkEgQ0ROIHRoYXQgcmVx dWlyZXMgaXNzIGNsYWltcyBzaG91bGQgcHJvYmFibHkgYmUgYWJsZSB0byBhZHZlcnRpc2UgaXQg dmlhIHRoZSBDRE5JIE1ldGFkYXRhIEludGVyZmFjZSBhcyB3ZWxsLiBJdCBtaWdodCBldmVuIGJl IHN0cmFpZ2h0Zm9yd2FyZCBlbm91Z2ggdG8gc2F5IHRoYXQgaWYgdGhlIENETkkgTWV0YWRhdGEg SW50ZXJmYWNlIFByb3BlcnR5IElzc3VlcnMgaXMgbm90IGVtcHR5LCB0aGUgaXNzIGNsYWltIGlz IHJlcXVpcmVkIGFuZCBpZiBpdCdzIGVtcHR5LCBpdCBtYXkgYmUgZWxpZGVkLiBUaGF0IGRvZXMg bGltaXQgc29tZSBzaXR1YXRpb25zLCB0aG91Z2guDQoNCktMPiBJ4oCZbSBub3Qgc3VyZSBpZiB0 aGlzIHdhcyBkaXNjdXNzZWQgYmVmb3JlIHdoZW4gZHJhZnQgY2hhbmdlZCB0byBKV1QgbWV0aG9k LiBJIHRoaW5rIG11bHRpcGxlIGtleXMgc2hvdWxkIGJlIHN1cHBvcnRlZCBzbyBraWQgY2FuIGJl IHVzZWQgdG8gaWRlbnRpZnkgdGhlIHJpZ2h0IGtleS4gWW91ciBsYXN0IHR3byBzZW50ZW5jZXMg c2hvdWxkIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBkcmFmdC4NCg0KDQpVUkkgYXR0cmlidXRl DQo9PT09PT09PT09DQpUaGUgVVJJIGF0dHJpYnV0ZSBjYW4gYmUgZW5jb2RlZCBpbiBlaXRoZXIg YSBxdWVyeSBwYXJhbWV0ZXIgb3IgYSBwYXRoIHBhcmFtZXRlci4gVGhlIGRyYWZ0IGltcGxpZXMs IGJ1dCBkb2VzIG5vdCBjbGVhcmx5IHN0YXRlLCB0aGF0IGEgY29uZm9ybWluZyBpbXBsZW1lbnRh dGlvbiBtdXN0IGFjY2VwdCBhIHZhbGlkIEpXVCBpbiBlaXRoZXIgbG9jYXRpb24uDQpUaGlzIHdv cmtzLCBidXQgY291bGQgcHJvYmFibHkgYmUgYSBiaXQgY2xlYXJlci4gQWxzbywgYW55IGltcGxl bWVudGF0aW9uIHRoYXQgZG9lcyB3aGF0IEknbSBnaXZlbiB0byB1bmRlcnN0YW5kIGlzIG5vdyBj YWxsZWQgIlRva2VuIFJlbmV3YWwiIG5lZWRzIHRvIGFjY2VwdCBKV1RzIHZpYSB3aGF0ZXZlciBt ZWNoYW5pc20gdGhleSB1c2UgYXMgd2VsbC4gU3BlY2lmaWNhbGx5LCB0aGUgc2VjdGlvbiBvbiBj ZG5pc3R0PTEgc3BlY2lmaWVzIHRoYXQgY29va2llcyBzaG91bGQgYmUgdXNlZCB0byBzZW5kIGFu ZCByZWNlaXZlIHRoZSByZW5ld2VkIHRva2VuLCBidXQgbm90aGluZyBzZWVtcyB0byBnaXZlIHRo ZSBDRE4gcGVybWlzc2lvbiB0byBsb29rIGFueXdoZXJlIGJ1dCB0aGUgcXVlcnkgYW5kIHBhdGgg cGFyYW1ldGVycyBmb3IgdGhlIEpXVC4NCg0KS0w+IEdvb2QgcG9pbnQuIEkgdGhpbmsgd2hlbiBj b250ZW50IHJlcXVpcmVzIFVSSSBTaWduaW5nIGVuZm9yY2VtZW50LCB0aGVuIENETiBzaG91bGQg bG9vayBmb3IgVVJJU2lnbmluZ1BhY2thZ2UgYXR0cmlidXRlLiBJZiBhdHRyaWJ1dGVkIGRvZXNu J3QgZXhpc3RzLCB0aGVuIENETiBsb29rcyBmb3IgVVJJU2lnbmluZ1BhY2thZ2UgY29va2llLiBJ cyB0aGlzIHN1ZmZpY2llbnQ/IE9yIGRvZXMgdGhpcyBhZGQgdG9vIG11Y2ggb3ZlcmhlYWQ/DQoN Cg0KSW4gYWRkaXRpb24sIHRoZSBkcmFmdCBkb2Vzbid0IGRlc2NyaWJlIGhvdyB0aGUgQ0ROIHNo b3VsZCBiZWhhdmUgd2hlbiBpdCBpcyBnaXZlbiBtdWx0aXBsZSBjb29raWVzLiBJbiBhIHRva2Vu LXJlbmV3YWwgc2l0dWF0aW9uLCB0aGlzIGlzbid0IGh5cG90aGV0aWNhbC4gQSBtYW5pZmVzdCBz aWduZWQgd2l0aCBhbiBleHBpcmVkIEpXVCBpcyBxdWl0ZSBsaWtlbHkgdG8gYmUgcHJlc2VudGVk IHdpdGggYSB2YWxpZCByZWNlbnRseS1yZW5ld2VkIGNvb2tpZS4NCg0KS0w+IE1heWJlIEknbSBt aXNzaW5nIHNvbWV0aGluZy4gU2hvdWxkbid0IHRoZSByZW5ld2VkIGNvb2tpZSBvdmVyd3JpdGUg dGhlIG9sZCBvbmU/IE9yIHRoZSBleHBpcmF0aW9uIHRpbWUgZm9yIHRoZSBjb29raWUgY2FuIGJl IHVzZWQ/DQoNCnJlbmV3YWwgcnVsZXMNCj09PT09PT09PT0NClRoZXJlIGlzbid0IG11Y2ggc2Fp ZCBhYm91dCB0aGUgdmFsdWVzIGluIHJlbmV3ZWQgdG9rZW5zLiBNb3N0IG9mIHRoZSBydWxlcyB0 aGF0IGFwcGx5IHRvIENETkkgcmVkaXJlY3Rpb24gbWFrZSBzZW5zZSBmb3IgdGhlIGV4YWN0IHNh bWUgcmVhc29ucyBmb3IgcmVuZXdlZCB0b2tlbnMuIFJpZ2h0IG5vdywgYSAicmVuZXdlZCB0b2tl biIgY2FuIGNvbnRhaW4gZGlmZmVyZW50IHZhbHVlcyBmb3IgbmVhcmx5IGFueXRoaW5nLiBUaGlz IHNob3VsZCBiZSBmbGVzaGVkIG91dCwgSSB0aGluaywgbW9zdGx5IGJ5IGFkZGluZyAib3IgU2ln bmVkIFRva2VuIFJlbmV3YWwiIGFmdGVyICJDRE5JIHJlZGlyZWN0aW9uIiBpbiBtb3N0IG9mIHRo ZSBjbGFpbXMuDQoNCktMPiBPSy4NCg0KDQpqdGkgY2xhaW0NCj09PT09PQ0KSSdtIG5vdCBlbnRp cmVseSBjbGVhciBvbiBob3cgdGhpcyB3b3VsZCB3b3JrIGluIGEgQ0ROIGVudmlyb25tZW50Lg0K VGhlIGRyYWZ0IGluZGljYXRlcyB0aGF0IGlmIGl0IGNvbnRhaW5zIGEgbm9uY2UsIHRoZSBDRE4g Y2FuIHZlcmlmeSB0aGF0IGl0IGhhc24ndCBiZWVuIHVzZWQgYmVmb3JlLiBCdXQgdGhhdCBtYWtl cyBub25jZS1jaGVja2luZyBhIHN5bmNocm9ub3VzIGV2ZW50IGFjcm9zcyB0aGUgZW50aXJlIENE Ti4gRm9yIGV2ZXJ5IHNpZ25lZCByZXF1ZXN0LCBpdCB3b3VsZCBoYXZlIHRvIGxvY2sgYSBnbG9i YWwgbGlzdCBvZiAidXNlZCBub25jZXMiLCBjaGVjayBpdCwgYWRkIHRoZSBuZXcgaXRlbSBvciBy ZWplY3QgdGhlIEpXVCwgdGhlIHVubG9jay4gVGhpcyBmZWVscyBzbG93LCBidXQgZGlmZmVyZW50 IHVzZSBjYXNlcyBtaWdodCB3YXJyYW50IGl0Lg0KDQpLTD4gSSB0aGluayB0aGlzIGRlcGVuZHMg b24gaW1wbGVtZW50YXRpb24uIEl0J3MgcG9zc2libGUgdGhhdCB0aGF0IG5vbmNlIHNwYWNlIGlz IHBhcnRpdGlvbmVkIGFjcm9zcyBTdXJyb2dhdGVzIHNlcnZpbmcgQ0ROLiBTbyBjaGVja2luZyBu b25jZSBjYW4gYmUgbG9jYWxpemVkIHRvIGVhY2ggU3Vycm9nYXRlLiBPciBvdGhlciBtZXRob2Rz IG1heSBiZSBpbXBsZW1lbnRlZCB0byBhZGRyZXNzIHRoZSB1c2Ugb2Ygbm9uY2UuDQoNCg0KVGhp cyBzZWN0aW9uIGFsc28gZG9lc24ndCBpbmNsdWRlIGVpdGhlciBNVVNUIG9yIE1BWSBsYW5ndWFn ZSBmb3IgYSBDRE4gdGhhdCBzdXBwb3J0cyBub25jZXMuIEluc3RlYWQsIGl0IGp1c3QgbWFrZXMg YSBzdGF0ZW1lbnQgYWJvdXQgd2hhdCBhIG5vbmNlIG1pZ2h0IGJlIHVzZWZ1bCBmb3IgaWYgYSBD RE4gZGlkIHNvbWUgcHJvYmFibHkgc2xvdyB0aGluZ3MuIEkgdGhpbmsgdGhpcyBjbGFpbSBzaG91 bGQgYmUgbW9yZSBzcGVjaWZpYyBhYm91dCB3aGF0IGEgQ0ROIE1VU1Qgb3IgTUFZIGRvIGlmIGl0 IHdhbnRzIHRvIGFsbG93IG5vbmNlcyB0byBiZSB1c2VkLg0KDQpLTD4gSSdtIG5vdCBxdWl0ZSBz dXJlIHdoYXQncyBuZWVkZWQgaW4gdGhlIGRyYWZ0LiBUaGVyZSdzIG5vIGludGVudCB0byBiZSBw cmVzY3JpcHRpdmUgaW4gdGV4dCBmb3Igc3VwcG9ydCBvZiBub25jZSBpbiBDRE4uIA0KDQpUaGFu a3MgYWdhaW4hDQoNCktlbnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg== From nobody Fri Oct 27 22:45:20 2017 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 497DF137C4A for ; Fri, 27 Oct 2017 22:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vR_9QSe05i00 for ; Fri, 27 Oct 2017 22:45:15 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D8C13F766 for ; Fri, 27 Oct 2017 22:45:14 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id j15so7854384wre.8 for ; Fri, 27 Oct 2017 22:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=0BEEPEOJGf1BtPtQNCpucfnwJCSI21yHHe89UyYwaUI=; b=BSNjWk+Bz/4aI7dnlDUYj9KZkvCkA0W9cqF3PLHkiWbJGcZ08YJFiWb1IwkHf3m/zZ 4JQ9T2/B/Bd0NZsXGZZCNs72YDRj9x9PenFYB6b4uij7kG0FOs4NNszko+STF37Suoyb mraozZn44mclHaHcWfeN1ySPUA9zz7sJseD2RUZm/4l9hAzaHUGUmey8+Y0oMit5lAPa /3AK/jOfWVxlt2KRDlNLEWcnzL5u17Ho08ydUDqj7n/0CXTZhcRMprcc+Wd6ATPEE5Fr p8fbmC7cxt48TXp6CTdSPoNqQ7MtsKQ3nu8lwA8MAsq/GVw+RvcdQJ73fk8fMpZn80cO A88A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=0BEEPEOJGf1BtPtQNCpucfnwJCSI21yHHe89UyYwaUI=; b=f0pvFwVOUm29jGq7322way2GTpcXTUbf6jmhc1zLkdCMv3nvd6vDTefm4EHqzklpA2 CPPbUqp/m74LZJFD8vmM+3aWVaPoElYlyzmyNuFxik9E4mhwbHB64lIfFmgIuV8SEZF8 nOQzL0XyIXisk1Y6PXXpJ716AYHWcBe8vFlFGqKMniByGFMl6l7/kvPsXHpvGm0bSiLj IThG6627Ptq1PcjEQm9+t6WaCorij8D1mX+l7UD4VLmGzz02AJhO/W69wCmHmLmmM7Ab iNYfoqMujsdoMp25hoG54j852hKJ+BgIYMi2gBKx4wNiFzMZNLaB+Kbj4UfA5emYJy9q v2Gw== X-Gm-Message-State: AMCzsaVbscvaE9r1MM7Z39MteNMiA8oiWlXG08I5mEnE8U9msKpTDuR3 y8SsWjSSs9UCYjz6DCr+SFgVBwB3C4GKaIslulgAhA== X-Google-Smtp-Source: ABhQp+SQCH/OiKiuSBK+yTrjD6mULXTblH8uX64rTibfsghwyRZCDj0KnAOJ9UzWoicUL5t3xgkvXomWF83awGTHJsM= X-Received: by 10.223.147.68 with SMTP id 62mr1992517wro.261.1509169512246; Fri, 27 Oct 2017 22:45:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.141 with HTTP; Fri, 27 Oct 2017 22:45:11 -0700 (PDT) In-Reply-To: <530871e72c32471d89ebebdbb99c059d@XCH-RTP-006.cisco.com> References: <530871e72c32471d89ebebdbb99c059d@XCH-RTP-006.cisco.com> From: Chris Lemmons Date: Fri, 27 Oct 2017 23:45:11 -0600 Message-ID: To: "cdni@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [CDNi] =?utf-8?q?URI_Signing_=E2=80=94_Feedback_from_an_Implemen?= =?utf-8?q?ter?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 28 Oct 2017 05:45:19 -0000 > The URI Container is meant to represent the URI in the forms described in= section 2.1.11. Right, but JWT requires that the sub claim be a "StringOrURI", with the specification "must be a URI" if it has a colon, which it always will. The definition of "URI" is as defined in RFC 3986. That definition does not allow the following URL to be valid, if I understand it correctly: uri-pattern:http://???.example.com/???/foo. I believe it was previously allowed in RFC 2396, but that's been obsoleted by 3986 which is what's referenced by the JWT spec. The intent of the sub claim is mostly clear here, but I think there's a technical conflict with RFC 3986 as included by RFC 7519. A simple fix would be to rename it "cdnisub" or something similar. You could leave the plain uri case in the "sub" claim with no prefix, if desired, though that might complicate things more than it simplifies them. > I agree that if the JWT is carried in the query string and path parameter= s, the JWT needs to be omitted part. Yeah, that was my gut reaction, too, though. It gets kinda tricky in the corners, though. The query string, as near as I can tell, is not a standardized component. It's typical to delimit key-value pairs with ampersands, but I don't think it's required. For about 15 years, splitting on semicolons instead was recommended, but not required. The current guidance is a recommendation by the w3c, I think: https://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-d= ata . That means that things like this are "legal": http://example.org/secret?foo&URISigningPackage=3DJWTGOESHERE& . Should the query here map to http://example.org/secret?foo& ? What if the parameter is the only one: http://example.org/secret?URISigningPackage=3DJWTGOESHERE =3D> http://example.org/secret . I think it's possible to define this, but processing it correctly can be tricky. A similar problem occurs with "path parameters". There's no RFC that defines them, so we'll probably need to define them as well. Removing them for matching is also rather tricky, for similar reasons. I can think of four solutions: 1. Rather than saying "query or path parameter", say "delimiter or sub-delimiter followed by parameter name, then JWT, terminated by a delimiter, sub-delimiter, or the end of the query. For evaluating matches, the parameter name, JWT, and terminating delimiter or sub-delimiter will be removed, unless the JWT is terminated by the end of the URI, in which case the preceding delimiter or sub-delimiter, parameter name, and JWT will be removed". Then, rather than having a parameter name of "URISigningPackage", you have one of "URISigningPackage=3D". For the purposes at hand, leaving the equals in there is mostly fine, but we've got a use case where we basically need to encode the token as a path element directly, because some poorly behaving clients become deeply confused at the sight of semicolons (and, probably, any other sub-delimiters) in the path. Providing a place to "override" the equals would accomplish this. Clarify that the URI will be processed left-to-right and only the first match will be evaluated. (There's no point in allowing multiple JWTs anyway.) 2. Carefully document the current recommendations on query strings and path parameters and encode them into the spec. Write rules similar to option 1 that clarify how and when the surrounding delimiters should be removed for matching with the parameter and its value. 3. Carefully document the current recommendations on query strings and path parameters and encode them into the spec. For matching purposes, remove all path parameters and the entire query string. 4. Carefully document the current recommendations on query strings and path parameters and encode them into the spec. For matching purposes, remove either the path parameters or the query string, depending on where the JWT is found. I like option 1, because it dodges the question of how to format all your query strings and path parameters, and allows it to adapt to reasonable changes in the future. It does, however mean that if you, for some reason, had an actual path element named "URISigningPackage=3D", you'd need to percent-encode some or all of the name, probably the equals. I'm not super-keen on documenting query strings or path parameters, but maybe we can find an appropriate reference to cite? Option 4 isn't great because it means that a url that matches when you pass the JWT in a path parameter is going to fail on the same path if you stick it in a cookie. In option 3, it's a blunt instrument, but it does keep the same matches when you switch to a cookie in token renewal. > I sense the example was targeted for HAS case where this URI was for the = video segment which would use signed token chain with cookie to carry the J= WT. But that's just my assumption as that would fit with the example. Maybe= the manifest file is likely to have signed URL without using signed token = chain. E.g., http://*/folder/content-83112371/manifest/*.xml(\?.*). Unfortunately, because the glob matches all things, even the example you gave is vulnerable to manipulation. What if you replaced the glob format with a "uri-path-prefix" container. It would match any container with a path prefix that matches exactly. For example: "uri-path-prefix:/folder/content-83112371/manifest/" would match "http://example.com/folder/content-83112371/manifest/important.xml?foo=3Dba= r". You'd still have regexes for the fancy stuff. Bonus points: it's really fast and dead simple to implement. Very low risk of a poor implementation going accidentally exponential. The other option is to make the glob and hook not match delimiters. Delimiters are pretty important, so people probably want to match those specifically. Again, if you want to match an arbitrary number of path elements, there are regexes. > Since =E2=80=9Caud=E2=80=9D is used for Client IP/IP prefix, the IPv6 add= ress has colon-based representation. That may be an issue? Since the value must be encrypted and encoded as a JWE, you dodge the colon problem here. The JWE can't have fancy chars in its representation. > I get your point. The draft uses =E2=80=9Caud=E2=80=9D as the intended re= ceiver (i.e. UA as identified by Client IP) of the requested content. It=E2= =80=99s a bit convoluted since I believe that =E2=80=9Caud=E2=80=9D in JWT = is for the intended recipient of the token (CDN). Perhaps we should introdu= ce a Client IP claim for CDN to match the source IP against the value? Renaming the field to "cdniip" makes the problem go away. For bonus points, you can put aud to its intended purpose and allow signers to specify which CDN is intended to accept a particular JWT, if that's desirable. > I don=E2=80=99t see a need for array. If you rename it, you get to re-pick the format. But I do see some uses for specifying multiple IPs. Dual stack boxes may need to be authorized to get data on either of their interfaces. An ISP might simply limit IPs to the range they provide to their customers, but not specify the exact customer's IP independently, which could involve a couple of distinct CIDRs. A very, very clever signer might know that a given mobile device has a mobile IP and a wifi IP and sign the ticket for both to allow some movement. Allowing multiple IPs provides some flexibility without increasing complexity that much. > So cdniets is not a time value, but a positive integer value that is used= to increase the expiration time of the matched URI. I would probably use a real number for consistency. There's no compelling implementation reason to limit it, since the implementation must already be using real values for time already. And it allows sub-second timeouts if a CDN required them. Maybe in a scenario where a CDN is serving a signed html page and using token renewal to allow the page to load javascript and image assets? Maybe in a few years when the Internet is so fast that 30ms seems like a lifetime? > Maybe I'm missing something. Shouldn't the renewed cookie overwrite the o= ld one? If the user requests http://example.com/content, they'll store the renewal cookie at /. If the user uses that ticket to request http://example.com/content/frag-1, they'll get another cookie and store it at /content. Then, when they request http://example.com/content/frag-2, they'll submit the cookie they got at / and the one they got at /content, in no particular order. The /content cookie keeps getting updated, but the / cookie eventually expires. Likewise, a client might be given a manifest with a token in the path: http://example.com/content;URISigningPackage=3DJWTGOESHERE/manifest.xml. It then follows that to http://example.com/content;URISigningPackage=3DJWTGOESHERE/frag-01. After a few requests, the original parameter in the path is no longer valid, but the client simply treats it as part of the path, so it doesn't know to remove it. There's still a valid renewed token in the cookie, though. > It's possible that that nonce space is partitioned across Surrogates serv= ing CDN. You're right. If a CDN can know which system will service a signed request, it can fairly easily localize nonce-checking. Either way, it's an implementation detail. > I'm not quite sure what's needed in the draft. There's no intent to be p= rescriptive in text for support of nonce in CDN. I was thinking a sentence like this: "If the signed JWT contains a Nonce claim and that Nonce has already been used, then the CDN MAY reject the request." I'd consider upgrading that to MUST, though. There's weasel room in the definition of "used", if an implementation really wants it. On Fri, Oct 27, 2017 at 4:56 PM, Kent Leung (kleung) wro= te: > Hi Chris. Thanks for the review comments. Plenty of items to parse throug= h, so sorry for the delay. Definitely, it's valuable to have implementer's = feedback. See my comments below. > > > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Chris Lemmons > Sent: Wednesday, October 4, 2017 2:43 PM > To: cdni@ietf.org > Subject: [CDNi] URI Signing =E2=80=94 Feedback from an Implementer > > I recently implemented (most of) URI Signing as an Apache Traffic Server = plugin. I used Draft 12 as my reference and I found a few rough edges that = could be polished a bit. I apologize in advance for the wall of text, but I= think it made more sense to collect my thoughts than it did to create a do= zen emails. It's worth noting, I've only implemented it in a single-CDN con= text, so I haven't fully exercised some of the pieces. > > > > sub claim URIs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > According to RFC 7519 =C2=A7 4.1.2, the sub claim is of StringOrURI type,= which specifies that while it may contain any value, if the value contains= a colon, it must be a URI as specified in RFC 3986. But although all valid= sub claims will contain a colon, very few are valid URIs. Even the example= given doesn't appear to be a valid URI: > > uri-pattern:*://*/folder/content-83112371/quality_*/segment????.mp4 > > It contains several ?s and *s that would not be legal in a URI, as near a= s I can tell. Maybe I missed something in the URI spec, but this claim real= ly doesn't feel like a URI to me. > > KL> The =E2=80=9C?=E2=80=9D and =E2=80=9C*=E2=80=9D are special literals = in the URI pattern for matching to an valid URI. I may be missing your poin= t. But the objective of uri-pattern is to specify the pattern match format = and not the exact URI. The URI Container is meant to represent the URI in t= he forms described in section 2.1.11. > > > sub claim Simple Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The URI includes the query string and path parameters, which includes the= JWT. The JWT cannot include a copy of itself. The only way this claim coul= d match something is if it were presented as part of a token renewal via co= okie. And that isn't terribly useful, since token renewal relies on regex/p= attern matches to match future requests. > > And simply dropping the query string entirely isn't a great option, becau= se the query string may contain other material that is important to match. = And that doesn't help the path-parameter case either. > > As near as I can tell, there is no useful use-case for the simple contain= er. > > KL> I agree that if the JWT is carried in the query string and path param= eters, the JWT needs to be omitted part. For consistency, the entire URI ex= cept the part containing the value for URISignPackage attribute is validate= d by match operation. This should happen regardless if cookies, query strin= g and path, etc. are used. > > > sub claim Hash Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This has the same problem as the simple container, just hashed in the mid= dle. The JWT can't contain a hashed copy of itself for chicken-and-egg reas= ons. (Technically, proving that mathematically feels hard, since it might b= e possible to contrive a JWT that contains a hash that matches a signed cop= y of itself. That's sufficiently impractical to call impossible, though, I = think.) > > > KL> This should be treated the same as above, by excluding JWT to avoid t= he chicken-and-egg situation. > > > sub claim Pattern Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The Pattern Container is strictly less powerful than the regex container.= And it uses a bespoke glob format that doesn't appear anywhere else, so ea= ch implementation will have to implement it from scratch. (This task isn't = terribly hard, but it's really easy to accidentally do it exponentially and= there are a few unobvious > gotchas.) > > And in practice, I'm not sure how useful the globbing is. For the most pa= rt, unexpected query parameters are simply ignored. That means the example = pattern: > > *://*/folder/content-83112371/quality_*/segment????.mp4 > > ... matches this URI: > > https://server.example.com/secret/file.xml?URISigningPackage=3DJWTGOESHER= E&hackery=3D/folder/content-83112371/quality_7/segmentcode.mp4 > > ... but not this URI: > > https://cdn.example.com/folder/content-83112371/quality_high/segment1234.= mp4?URISigningPackage=3DJWTGOESHERE > > Given the widespread behaviour of handling query strings, few, if any, is= suers would be able to meaningfully use the glob anywhere but in the last p= lace. You definitely don't want people trying to use it like it is describe= d in the examples. > > > KL> I know that was Ray=E2=80=99s proposal. I sense the example was targe= ted for HAS case where this URI was for the video segment which would use s= igned token chain with cookie to carry the JWT. But that's just my assumpti= on as that would fit with the example. Maybe the manifest file is likely to= have signed URL without using signed token chain. E.g., http://*/folder/co= ntent-83112371/manifest/*.xml(\?.*). > > > sub claim Regex Container > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This container is the most powerful of all the containers. Everything exp= ressible in one of the other containers can be expressed here as well. The = examples here are likely to lead people astray though. The example regex: > > .*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4 > > ... should probably be: > > [^:]*\\://[^/]*/folder/content-83112371/quality_[^/]*/segment.{3}\\.mp4(\= ?.*)? > > Universal globs aren't terribly useful since they're very vulnerable to U= RL manipulation. The examples should use exclusionary patterns that end on = the delimiting character. Also, the query is part of the pattern, so it nee= ds to be part of the regex as well. > > The regex and pattern containers both don't specify that the patterns are= anchored (no extra stuff is allowed on either end), but it seems implied a= nd if it weren't anchored, it would be largely useless because of URI manip= ulation. The sub containers should probably specify that the pattern must m= atch the entire URI. > > KL> I'm OK with your suggested example string. > > > aud claim > =3D=3D=3D=3D=3D=3D=3D > According to RFC 7519 =C2=A7 4.1.3, the aud claim is either a StringOrURI= or an array thereof. The draft describes what to do with a single string (= which helpfully cannot contain a colon), but doesn't discuss the array case= . I don't know that there's a strong reason to include the array format as = legal, but I also don't know that there's a strong reason contrariwise. Eit= her way, though, the draft should probably pick a side and document it. > > KL> Since =E2=80=9Caud=E2=80=9D is used for Client IP/IP prefix, the IPv6= address has colon-based representation. That may be an issue? I don=E2=80= =99t see a need for array. Though the language in RFC 7519 covers the case = of a single StringOrURI case already (=E2=80=9CIn the special case when the= JWT has one audience, the "aud" value MAY be a single case-sensitive strin= g containing a StringOrURI value.=E2=80=9C) > > > Additionally, that section specifies that: > >> If the principal processing the claim does not identify itself with a va= lue in the "aud" claim when this claim is present, then the JWT MUST be rej= ected. > > The interpretation of the value is generally application specific, but it= would be very strange to say that the "principal processing the claim" (th= e CDN) identifies itself with the value in the aud claim (the Client's IP a= ddress). > > The aud claim seems to be designed to limit who will accept the token. > It feels somewhat co-opted in this situation. > > > KL> I get your point. The draft uses =E2=80=9Caud=E2=80=9D as the intende= d receiver (i.e. UA as identified by Client IP) of the requested content. I= t=E2=80=99s a bit convoluted since I believe that =E2=80=9Caud=E2=80=9D in = JWT is for the intended recipient of the token (CDN). Perhaps we should int= roduce a Client IP claim for CDN to match the source IP against the value? > > > cdniets default > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The cdniets field does not have a default value. It's legal for an issuer= to elide this value even when providing a cdnistt of 1. It should either h= ave a non-zero default value or be required when cdnistt is 1. > > Additionally, all other time values are real, this one is integer. The pr= ecision is probably not critical, but consistency is probably better. > > > KL> I think cdniets should be required when cdnistt is 1. Draft should be= explicit. I'm OK with using NumericDate (real) type for consistency. But y= our next point makes me think it's better to be an integer to indicate the = time delta and not absolute time that is requested. So cdniets is not a tim= e value, but a positive integer value that is used to increase the expirati= on time of the matched URI. Would that be OK? > > > cdniets claim > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This should be added to the iat, not the exp. A crafty malefactor who wis= hes to share his url for all to use could simply repeatedly request the sam= e small file more frequently than it expires. As specified in the draft, th= is would cause the exp to continuously extend. This could easily be used to= create a "renewed" token that lasts for years. > > A CDN renewing a token should always add the the extension time to curren= t time, instead, to get the expiration time. > > KL> Good point. The current time should be used as reference for increasi= ng the time delta for expiration to prevent additive extension. > > > nbf leap seconds > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If issuers set nbf claims to the iat time, this will cause conforming imp= lementations to incorrectly reject JWTs during leap seconds. This is an iss= ue inherited from the JWT specification, but it's more serious in a token-r= enewal context, since it can cause a large number of streaming video client= s to simultaneously stutter or disconnect. > > According to RFC 7419 and the POSIX specification it references, a leap s= econd is required to "repeat" at the beginning of the next day. > This will cause all issued tokens to be invalid for about a second. > (If implementations "smear" the leap second in contravention of the POSIX= spec, this will not be an issue, so long as the issuer and CDN are synchro= nized.) > > Since the issue is largely inherited from the JWT RFC, I don't know that = it makes sense to attempt to fix it here. I just happened to run into it he= re. But a cautionary note that one should not set nbf to the current time m= ight be valuable. > > > > key identification > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > When verifying a JWT, I need to know which key should be used to verify i= t. In my implementation, I use a combination of the iss claim and the kid i= n the JOSE header. But neither of those values are required. And as near as= I can tell, the draft does not allow me to require them. It says I MAY use= it to identify the key, but doesn't say I may reject an otherwise valid JW= T that doesn't have an iss claim. > > Likewise, the JOSE kid header (RFC 7515 =C2=A7 4.1.4) is necessary to ide= ntify the specific key. > > As written, I don't believe I can deny an otherwise valid JWT for missing= these fields. But the only way I can determine that it's valid is to try a= ll the keys that could potentially be valid, which may be a very large numb= er of keys (issuers can use many keys and a CDN may easily have multitudino= us valid issuers). The CDN has a trust relationship with the issuers, so I = can be sure that a signed JWT won't abuse my resources, but key identificat= ion by necessity must occur before verification. So, a malefactor who prese= nts an invalidly signed JWT that lacks an iss claim and kid header can caus= e significant resource waste by forcing me to check all possible keys. > > A CDN should be able to reject a claim that doesn't present a valid issue= r/kid combination. (It shouldn't be required to, of course, since it might = only support a single key and it might be a non-issue.) > > A CDN that requires iss claims should probably be able to advertise it vi= a the CDNI Metadata Interface as well. It might even be straightforward eno= ugh to say that if the CDNI Metadata Interface Property Issuers is not empt= y, the iss claim is required and if it's empty, it may be elided. That does= limit some situations, though. > > KL> I=E2=80=99m not sure if this was discussed before when draft changed = to JWT method. I think multiple keys should be supported so kid can be used= to identify the right key. Your last two sentences should be incorporated = into the draft. > > > URI attribute > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The URI attribute can be encoded in either a query parameter or a path pa= rameter. The draft implies, but does not clearly state, that a conforming i= mplementation must accept a valid JWT in either location. > This works, but could probably be a bit clearer. Also, any implementation= that does what I'm given to understand is now called "Token Renewal" needs= to accept JWTs via whatever mechanism they use as well. Specifically, the = section on cdnistt=3D1 specifies that cookies should be used to send and re= ceive the renewed token, but nothing seems to give the CDN permission to lo= ok anywhere but the query and path parameters for the JWT. > > KL> Good point. I think when content requires URI Signing enforcement, th= en CDN should look for URISigningPackage attribute. If attributed doesn't e= xists, then CDN looks for URISigningPackage cookie. Is this sufficient? Or = does this add too much overhead? > > > In addition, the draft doesn't describe how the CDN should behave when it= is given multiple cookies. In a token-renewal situation, this isn't hypoth= etical. A manifest signed with an expired JWT is quite likely to be present= ed with a valid recently-renewed cookie. > > KL> Maybe I'm missing something. Shouldn't the renewed cookie overwrite t= he old one? Or the expiration time for the cookie can be used? > > renewal rules > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > There isn't much said about the values in renewed tokens. Most of the rul= es that apply to CDNI redirection make sense for the exact same reasons for= renewed tokens. Right now, a "renewed token" can contain different values = for nearly anything. This should be fleshed out, I think, mostly by adding = "or Signed Token Renewal" after "CDNI redirection" in most of the claims. > > KL> OK. > > > jti claim > =3D=3D=3D=3D=3D=3D > I'm not entirely clear on how this would work in a CDN environment. > The draft indicates that if it contains a nonce, the CDN can verify that = it hasn't been used before. But that makes nonce-checking a synchronous eve= nt across the entire CDN. For every signed request, it would have to lock a= global list of "used nonces", check it, add the new item or reject the JWT= , the unlock. This feels slow, but different use cases might warrant it. > > KL> I think this depends on implementation. It's possible that that nonce= space is partitioned across Surrogates serving CDN. So checking nonce can = be localized to each Surrogate. Or other methods may be implemented to addr= ess the use of nonce. > > > This section also doesn't include either MUST or MAY language for a CDN t= hat supports nonces. Instead, it just makes a statement about what a nonce = might be useful for if a CDN did some probably slow things. I think this cl= aim should be more specific about what a CDN MUST or MAY do if it wants to = allow nonces to be used. > > KL> I'm not quite sure what's needed in the draft. There's no intent to b= e prescriptive in text for support of nonce in CDN. > > Thanks again! > > Kent > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Oct 30 12:33:25 2017 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 8329913B488 for ; Mon, 30 Oct 2017 12:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 J1o36phORnfb for ; Mon, 30 Oct 2017 12:33:22 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E428413F60E for ; Mon, 30 Oct 2017 12:33:21 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 9966E12048A for ; Mon, 30 Oct 2017 20:33:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 83B27180063 for ; Mon, 30 Oct 2017 20:33:20 +0100 (CET) Received: from OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0361.001; Mon, 30 Oct 2017 20:33:20 +0100 From: To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-02.txt Thread-Index: AQHTUbVzuuSDSylOI0G/lquYsinONqL8x4gQ Date: Mon, 30 Oct 2017 19:33:19 +0000 Message-ID: <18303_1509392000_59F77E80_18303_12_1_1BD328329726EF4E91AE924BB1B4CB9E5CC5D442@OPEXCLILMA1.corporate.adroot.infra.ftgroup> References: <150939178679.7861.13355468587403483754.idtracker@ietfa.amsl.com> In-Reply-To: <150939178679.7861.13355468587403483754.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 30 Oct 2017 19:33:24 -0000 RGVhciBhbGwsDQoNCkkndmUganVzdCBwb3N0ZWQgYW4gdXBkYXRlIG9mIHRoZSBkcmFmdCB0aGF0 IHByb3Bvc2VzIGFuIGV4dGVuc2lvbiB0byBzdXBwb3J0ICBIVFRQUyBkZWxpdmVyeSBkZWxlZ2F0 aW9uIGluIENETkkuDQoNClJlZ2FyZHMsDQpGcsOpZMOpcmljDQoNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb24tMDIu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEZyZWRlcmljIEZpZWF1IGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWZpZWF1LWNk bmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJQ0RO SSBleHRlbnNpb25zIGZvciBIVFRQUyBkZWxlZ2F0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE3LTEw LTMwDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMw0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maWVhdS1j ZG5pLWludGVyZmFjZXMtaHR0cHMtZGVsZWdhdGlvbi0wMi50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWVhdS1jZG5pLWludGVyZmFj ZXMtaHR0cHMtZGVsZWdhdGlvbi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb24tMDIN Ckh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWZpZWF1LWNkbmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uLTAyDQpEaWZmOiAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWZpZWF1LWNkbmkt aW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uLTAyDQoNCkFic3RyYWN0Og0KICAgVGhlIGRlbGl2 ZXJ5IG9mIGNvbnRlbnQgb3ZlciBIVFRQUyBpbnZvbHZpbmcgbXVsdGlwbGUgQ0ROcyByYWlzZXMN CiAgIGNyZWRlbnRpYWwgbWFuYWdlbWVudCBpc3N1ZXMuICBUaGlzIGRvY3VtZW50IHByb3Bvc2Vz IGV4dGVuc2lvbnMgaW4NCiAgIENETkkgQ29udHJvbCBhbmQgTWV0YWRhdGEgaW50ZXJmYWNlcyB0 byBzZXR1cCBIVFRQUyBkZWxlZ2F0aW9uIGZyb20gYQ0KICAgdUNETiB0byBhIGRDRE4uDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Oct 30 13:43:32 2017 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 7FF3713F567 for ; Mon, 30 Oct 2017 13:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=qwilt-com.20150623.gappssmtp.com 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 9pBMZKrlkFqJ for ; Mon, 30 Oct 2017 13:43:29 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C6B137E0B for ; Mon, 30 Oct 2017 13:43:29 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id v27so10477712uav.7 for ; Mon, 30 Oct 2017 13:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iukr3BXjeEMCSpZ9FQMvS8Cy+xy/kTJdT445PAdgsYY=; b=rao1YvxpVFyYtzydLkVgMVdUlVmA7HYx8DZ3pKLF22r6caaNLc9B4p2R+Rn5/uO5Ae fXkQ9k8BzUO1dtCn/g/FNzqrWaeY/eCXC6HLjw7DJDQWWfbCGSWw+BpUry1VQ330+83a JJJIqqQ83l7siskxfJtKoaDNTFskLeLd/uUbaMQXQ+fdBqS1flXk1OYmfhtjvlgfaGiA Y77Bgsb9wVa4jWovRwgKpRp3/wFQng4CsGyhKzZ1YgN1PG+NIhQ3mY6+mBaLglCr9IIh 8sfHRzi5r0uDP+IVnwNUObUuhbfGlap7Ugz3F7GQbt7bm30oSJ7vjbVZ1KtvJKL2nbYK dfLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iukr3BXjeEMCSpZ9FQMvS8Cy+xy/kTJdT445PAdgsYY=; b=kHhEDQI4E5DDTP+Vdfgy3CYn/mkR0nhjm+W8L+A8kPgXfZ2waZlLP0bb2gy/VZrLuC nypAkpTeCg9r2BC2EOHeukm73Q4HIBf29NOSyLa2uZrViHysHvOKzp8lm4y68rKhk6xY oeN4RAevOja7Ni0415ZpNswVOPjswQyzlVfW9A/JEKaQre61LbX+PLyxewprEhlic40W hyInKgmmuP2YoED5/NRTHW+p/DAshSJCNfAwDlYqGwNWRq/GxUvy8GWwjtE+DDb4jnMu 9HTPtCg2qYtxjTAAWH3bnPPqmZJb7DG3ftUQ+TZHcX3fI8XmaCe5DsEpORaRFlyrcWAj zayw== X-Gm-Message-State: AMCzsaXiWrLhtslX1TUXv1RLiSbusM3Xl4gUCoiD8/bd8OQjYKhwMZzA AHh5wCfmCPh8KBvR4qxn5MchIUq6KN11LI0Jv/W9Tu7f X-Google-Smtp-Source: ABhQp+Qm0MR3aW03hVB/VbAgT6pc9AzCyOIRIFZD0MSkQUn8Y8IyZy3ChIh8mREOUEXOM1Fwd7bMYtCFj+lOf0HGg7g= X-Received: by 10.159.60.42 with SMTP id u42mr8567222uah.37.1509396207846; Mon, 30 Oct 2017 13:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.153.5 with HTTP; Mon, 30 Oct 2017 13:42:57 -0700 (PDT) In-Reply-To: <150937917932.7823.7624674920223255542.idtracker@ietfa.amsl.com> References: <150937917932.7823.7624674920223255542.idtracker@ietfa.amsl.com> From: Ori Finkelman Date: Mon, 30 Oct 2017 22:42:57 +0200 Message-ID: To: cdni@ietf.org Content-Type: multipart/alternative; boundary="f403043edd94cb5a48055cc9b0c0" Archived-At: Subject: [CDNi] Fwd: New Version Notification for draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 30 Oct 2017 20:43:31 -0000 --f403043edd94cb5a48055cc9b0c0 Content-Type: text/plain; charset="UTF-8" Dear CDNI working group, I have just submitted a draft for extension proposals for CDNI, These extensions are derived from the work done within the Open Caching working group of the Video Streaming Alliance (SVA). Open Caching is a specific case of CDNI and therefore we are looking to standardized these extensions and proposed new functionalities under the CDNI wg. Looking forward to get feedback from the cdni group. Best regards, Ori A new version of I-D, draft-finkelman-cdni-sva-extensions-00.txt has been successfully submitted by Ori Finkelman and posted to the IETF repository. Name: draft-finkelman-cdni-sva-extensions Revision: 00 Title: CDNI SVA Extensions Document date: 2017-10-30 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-finkelman-cdni-sv a-extensions-00.txt Status: https://datatracker.ietf.org/doc/draft-finkelman-cdni-sva-e xtensions/ Htmlized: https://tools.ietf.org/html/draft-finkelman-cdni-sva-extens ions-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-finkelman-cdni- sva-extensions-00 Abstract: 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). 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. The IETF Secretariat -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: +972-52-3832189 <052-383-2189> | orif@qwilt.com --f403043edd94cb5a48055cc9b0c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CDNI working group,
<= div class=3D"gmail_quote">I have just submitted a draft for extension propo= sals for CDNI,=C2=A0
These extensions are d= erived from the work done within the Open Caching working group of the Vide= o Streaming Alliance (SVA).
Open Caching is= a specific case of CDNI and therefore we are looking to standardized these= extensions and proposed new functionalities under the CDNI wg.

Looking forward t= o get feedback from the cdni group.

Best regards,
Ori



A new version of I-D, draft-finkelman-cdni-sva-extensions-00.txt
has been successfully submitted by Ori Finkelman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-finkelman-cdni-sva-exte= nsions
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CDNI SVA Extensions
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 25
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-fi= nkelman-cdni-sva-extensions-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-finkelman-cdni-sva-= extensions/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-finkelman-cdni-sva-extensions= -00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-finkelman-cdni= -sva-extensions-00


Abstract:
=C2=A0 =C2=A0The Open Caching working group of the Streaming Video Alliance= is
=C2=A0 =C2=A0focused on the delegation of video delivery request from comme= rcial
=C2=A0 =C2=A0CDNs to a caching layer at the ISP.=C2=A0 In that aspect, Open= Caching is
=C2=A0 =C2=A0a specific use case of CDNI, where the commercial CDN is the u= pstream
=C2=A0 =C2=A0CDN (uCDN) and the ISP caching layer is the downstream CDN (dC= DN).





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-383= 2189 | orif@qwilt.com
--f403043edd94cb5a48055cc9b0c0-- From nobody Mon Oct 30 14:54:48 2017 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 890BC13FBED; Mon, 30 Oct 2017 14:54:46 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940048652.7744.13033677512462824266@ietfa.amsl.com> Date: Mon, 30 Oct 2017 14:54:46 -0700 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-13.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 30 Oct 2017 21:54:46 -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-13.txt Pages : 36 Date : 2017-10-30 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) [RFC7519] 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-13 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 Oct 30 18:09:20 2017 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 B604213F9B9 for ; Mon, 30 Oct 2017 18:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5H0mX70plH_X for ; Mon, 30 Oct 2017 18:09:18 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37ECF13F98D for ; Mon, 30 Oct 2017 18:09:18 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b190so17083901lfg.9 for ; Mon, 30 Oct 2017 18:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GXX2X9NPQz1TAetFfSqxPWZxbTU3LZzFS+wGlXULpvM=; b=iCIVcxlyat+7nM+vzhf2n0cYN/mXcpzvZg9AVEh5zW8mqR6MNHXZl5Kg3WkiEXSfhX 0p0zIlX39C9lkY1Arftz9JaAciIQytHgLbqIbG0a2ygIkLVnjIXhM2Figaw5Yf2+JUfA u3JWkUC0pxVt/E7MfWTZKiVBy9v0SL0nQwxsy3TPeZdRQ4nDqw36EqAL6bMfrVHv1S0O W6vFnjW7z/JMJZ2H8UFai9BuleuKIjhHKjMYEQH3WAmfxs2+2avy14QacCoYkwbH4/8K +snJ/h8KKm5exW8S2GaxgECh2a8qBEefNxSxweWJQ1JFBPXoMAqCHvuqp5mh0YbEMxWX p+Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GXX2X9NPQz1TAetFfSqxPWZxbTU3LZzFS+wGlXULpvM=; b=SttLZohsKsUtoybEP/PdJCDnIiA0qY73GUG+JASGED4M+WqF/vgLSYqPBUStYyUJ4W btfVXbBby7Dn0p3+/yFihf0U4XUlkgtUoBk3qLBFwwidKw3Z/ig4+ALuxzxYXLiFlEQs u/6ZC/2v11jCpsmyQ6aL9JatRao4J//EwL3Md33BQJdipP8+BOle0QnoGPJ9cnyhFYw4 ilhsQfixc++nBZAm9JQpVmTz921xzsBXxksFszKLlLknL6w1u0MtbwyEHtYICdJS6XLI p/ZGXBLe6CD4L/bkaRbKzvJEQyj/2oKuQL0wmPhpMyGVQ+jJjGWL8kUwJ+9VkANmUElM N08A== X-Gm-Message-State: AMCzsaW+9Brm4avbcih2Z8Rh5dsda7ivRD9bz4oygGPOpHCxUsNao/lo ugTK4XWecL4g0pj4cxjp4j/edNO7+tun0WZgwCSI6A== X-Google-Smtp-Source: ABhQp+TRk+uNMs11UP9sR7gdWviBsYt5XLnSSWZAWklE/tpo2fmaa+vsyQr8IekCq3heub7GIh+tHNpqr8oENVnxguY= X-Received: by 10.25.79.74 with SMTP id a10mr79930lfk.162.1509412156318; Mon, 30 Oct 2017 18:09:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.229.9 with HTTP; Mon, 30 Oct 2017 18:09:15 -0700 (PDT) From: Kevin Ma Date: Mon, 30 Oct 2017 21:09:15 -0400 Message-ID: To: cdni@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1cd2e665a90a055ccd67b6" Archived-At: Subject: [CDNi] IETF 100 Draft Agenda X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 31 Oct 2017 01:09:20 -0000 --94eb2c1cd2e665a90a055ccd67b6 Content-Type: text/plain; charset="UTF-8" Hi All, We have posted the draft agenda for Singapore: https://datatracker.ietf.org/meeting/100/materials/agenda-100-cdni/ thanx! -- Kevin and Francois --94eb2c1cd2e665a90a055ccd67b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

=C2=A0 We have posted the draft= agenda for Singapore:=C2=A0https://datatracker.ietf.org/meeting/100/m= aterials/agenda-100-cdni/

thanx!
--=C2=A0 Kevin and Francois

--94eb2c1cd2e665a90a055ccd67b6--