Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

> On Aug 16, 2017, at 8:01 PM, Martin Thomson <[e-mail]> wrote:
> 
> On 17 August 2017 at 01:52, Ben Campbell <[e-mail]> wrote:
> 
>>> I think that "MAY" is entirely appropriate given the non-blocking
>>> nature of the mechanism. A push service might look at the header
>>> field, but not require the token. Maybe they just wanted to attach an
>>> email address to a stream of messages (that's what we do).
>> 
>> I think there’s a fundamental difference between not validating in the first place, and ignoring a failed validation. My point is not to say that ignoring it is the wrong thing to do, just that I think some more elaboration here is needed. Would it make sense to say something of the effect of “SHOULD NOT use the information from a token that has failed validation”?
> 
> That's easy.  MUST NOT even.  I added:  "A push service MUST NOT use
> information from an invalid token.”
> 

WFM. I will clear.


>>> In NSS and many elliptic curve libraries, you can create an EC key for
>>> P-256.  You can then use that key for signing AND key exchange.  You
>>> shouldn't though.
>> 
>> Would it make sense to say “Some library implementations…”?
> 
> The PR says "Some elliptic curve implementations ".  I think that's better.

Also WFM.

> 
>> Oops, that was a cut and paste error. I meant to quote the following sentence:
>> 
>> " A push service MAY reject a
>>   message that includes invalid credentials with a 403 (Forbidden)
>>   status code. "
> 
> I'll respond below.
> 
>>> This section defines behaviour in the case that a
>>> subscription is limited to a particular application server key.  I
>>> realize now that this might have been unclear, so I have reworded to:
>>> 
>>> "A push service MUST reject a message sent to a restricted push subscription if
>>> that message includes no "vapid" authentication or invalid "vapid"
>>> authentication.  A 401 (Unauthorized) status code might be used if the
>>> authentication is absent; a 403 (Forbidden) status code might be used if
>>> authentication is invalid."
>>> 
>>> This also allows me to clear up a minor gripe about the prescriptive
>>> nature of the text regarding status codes.
>> 
>> I like that paragraph better, but does it conflict with the text in section 2, as discussed in my DISCUSS?
> 
> The key point here is that the rejection mandated in Section 4.2 is
> specific to *restricted* subscriptions.  The text in Section 2 (above)
> is a more general statement.  I don't think that the two are in
> conflict.

Okay.

[…]