Subject: Re: [CDNi] Comments on draft 16

From: Phil Sorber <[email-masked]>
Date: Mon, 11 Mar 2019 15:55:10 -0600

Sorry, my mistake on the reply. Didn't go to the list the first time.

On Mon, Mar 11, 2019 at 3:54 PM Phil Sorber <[email-masked]> wrote:

> Document editor hat on...
>
> Sorry for the late reply. Responses inline below.
>
> On Wed, Feb 6, 2019 at 9:40 AM Kolev, Nikola <[email-masked]>
> wrote:
>
>> Hello,
>>
>>
>>
>> I am not sure what the protocol for providing feedback to this memo is so
>> I have included it in this email below. Please let me know what the
>> preferred method is and I would resubmit.
>>
>>
>>
>> Thanks,
>>
>> Nikola Kolev
>>
>>
>>
>> (Re)
>>
>> 2.1.2.  Subject (sub) claim
>>
>>
>>
>>    Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2
>>
>>    MUST be followed.  If this claim is used, it MUST be a JSON Web
>>
>>    Encryption (JWE [RFC7516]) Object in compact serialization form,
>>
>>    because it contains personally identifiable information.
>>
>>
>>
>> Comment: Why? The subject claim does not necessarily need to contain PII.
>> Also, it would be better that the specification leaves this claim's
>> encoding to "service providers" which may choose a "more optimal", than
>> JWE, encoding scheme even in the case where the claim carries PII and (some
>> portion of) the claim is encrypted.
>>
>>
> Definitions if PII vary greatly. The IETF is very privacy conscious as an
> organization. It was decided that the best course of action is to treat the
> entire claim as PII regardless. Consider that it's likely a unique
> identifier, which may not be name/IP address but can be uniquely
> identifying anyway. And since we are so privacy conscious, we wanted to
> specify a method of encryption that we deemed safe instead of letting
> operators use ROT13 and calling it a day.
>
>
>>
>>
>> (Re)
>>
>> 2.1.4.  Expiry Time (exp) claim
>>
>>
>>
>>    Expiry Time (exp) [optional] - The semantics in [RFC7519]
>>
>>    Section 4.1.4 MUST be followed, though URI Signing implementations
>>
>>    .. .. or if the Expiry Time in
>>
>>    the signed JWT corresponds to a time earlier than the time of the
>>
>>    content request, the CDN MUST reject the request. .. .. ..
>>
>>
>>
>> Comment: If I am not mistaken the `exp` claim carries **on** or after
>> semantics. Hence the memo should read not just **earlier**, as on should
>> result in rejection as well.
>>
>
> Noted.
>
>
>> (Re)
>>
>> 2.1.9.  CDNI Critical Claims Set (cdnicrit) claim
>>
>>
>>
>>    CDNI Critical Claims Set (cdnicrit) [optional] - The cdnicrit claim
>>
>>    indicates that extensions to this specification are being used that
>>
>>    MUST be understood and processed.  Its value is a comma separated
>>
>>    listing of claims in the Signed JWT that use those extensions.
>>
>>
>>
>>
>>
>> Comment: Should be specified as list. Same as the `crit` header claim,
>> https://tools.ietf.org/html/rfc7515#section-4.1.11. "Its value is a
>> comma separated..." could be misinterpreted as a StringOrURI carrying a CSV
>> value.
>>
>
> The working group decided that the JWT object should be flat, which means
> no lists. It would be correct to interpret this as a StringOrURI carrying a
> CSV value. You will note that we did not link back to the "crit" claim in
> 7515 that you referenced, and explicitly named it "cdnicrit".
>
>
>>
>>
>> (Re)
>>
>> 2.1.11.  CDNI URI Container (cdniuc) claim
>>
>>
>>
>>    URI Container (cdniuc) [optional] - Container for holding the URI
>>
>>    representation before a URI Signing Package is added.  This
>>
>>    representation can take one of several forms detailed in
>>
>>    Section 2.1.15.  If the URI regex ..
>>
>>
>>
>> Comment: URI regex is only one of the forms that the claim can assume.
>>
>
> Noted. That looks vestigial. The prior sentence has the correct semantics.
>
>
>>
>>
>> (Re)
>>
>> 6.4.  CDNI URI Signing Signed Token Transport
>>
>>
>>
>>    The "CDNI URI Signing Signed Token Transport" namespace defines the
>>
>>    valid values that may be in the Signed Token Transport (cdnistt) JWT
>>
>>    claim.
>>
>>
>>
>>    The following table defines the initial Enforcement Information
>>
>>    Elements:
>>
>>
>>
>>     +-------+-------------------------------------------+---------+
>>
>>     | Value | Description                               | RFC     |
>>
>>     +-------+-------------------------------------------+---------+
>>
>>     | 0     | Designates token transport is not enabled | RFCthis |
>>
>>     | 1     | Designates token transport via cookie     | RFCthis |
>>
>>     +-------+-------------------------------------------+---------+
>>
>>
>>
>> Comment/Question: I would imagine a system where the CDN is not the
>> authority that handles token renewals, but instead the CDN sends the user
>> agent back to the original token issuer. Can the working group consider
>> this architecture and expand the list of “token transport” mechanisms, to
>> include for example HTTP redirects?
>>
>
> HTTP redirects have been discussed, but a specific proposal has never been
> put forward. The publishing of this document does not preclude such a
> proposal from taking shape at a later date.
>
>
>>
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cdni
>>
>