Re: [Id-event] Review of draft-ietf-secevent-http-push-05

[Marius Scurtescu <[e-mail]>]

Thanks for the feedback Mark and for the suggested edits Annabelle.

I am incorporating the two suggested changes into a PR, along with other
feedback.

On Fri, Apr 12, 2019 at 11:45 AM Richard Backman, Annabelle <richanna=
[e-mail]> wrote:

> Thanks for the review, Mark! [richanna]Responses inline[/richanna].
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Id-event <[e-mail]> on behalf of Dick Hardt <
> [e-mail]>
> *Date: *Thursday, April 11, 2019 at 2:09 PM
> *To: *Mark Dobrinic <[e-mail]>
> *Cc: *Yaron Sheffer <[e-mail]>, "Richard Backman, Annabelle"
> <[e-mail]>, SecEvent <[e-mail]>
> *Subject: *Re: [Id-event] Review of draft-ietf-secevent-http-push-05
>
>
>
> Mark: thanks for the review and feedback
>
>
>
> Annabelle: have you had a chance to review the feedback?
>
>
>
> On Wed, Mar 27, 2019 at 3:55 AM Mark Dobrinic <[e-mail]>
> wrote:
>
> Hi id-event,
>
> Read through draft 05, and here's some of my findings. With the
> disclaimer that I am not fully aware of the historical discussions that
> led to this draft.
>
> - Section 2.0 mentions: "Once a SET has been validated and persisted,
> the SET Recipient SHOULD immediately return a response ..."; there's a
> bit of a gap on what to do when the SET was validated but failed to
> persist. The errors don't (and probably shouldn't?) cover this, as this
> might be considered business logic on the recipient's part? Section 2.2
> talks about "appropriate retention requirements", which is nicely
> formulated. This type of wording might be also snuck in to the language
> of section 2.0's paragraph ("Once the SET has been validated and
> persisted ..")
>
>
>
> [richanna]
>
> Persistence failures are no different from any other business logic
> failure on the SET Recipient side. In such cases the SET Recipient would
> return a 500, as allowed for by the first paragraph of 2.3:
>
>
>
> In the event of a general HTTP error condition, the SET Recipient
>
> SHOULD respond with an appropriate HTTP Status Code as defined in
>
> Section 6 of [RFC7231].
>
>
>
> The paragraph in 2.0 before the one you quote recommends the SET Recipient
> persist the SET “in a way that is sufficient to meet [their] reliability
> requirements”. This seems to me to provide the same guidance as the text in
> 2.2; do you feel that something is missing or unclear from that paragraph?
>
> [/richanna]
>
>
> - Is the `description` field in the error response REQUIRED?
>
>
>
> [richanna]
>
> Yes, both `err` and `description` are REQUIRED. The second paragraph of
> 2.3 contains the text:
>
>
>
> …the body [of the error response] MUST be a UTF-8 encoded JSON [RFC7159]
> object containing the following name/value pairs:
>
>
>
> …followed by the `err` and `description property definitions.
>
> [/richanna]
>
>
> - Is there a reason why the `authentication_failed` failure response
> should not return a HTTP/401 Unauthorized HTTP status code?
>
> [richanna]
>
> HTTP status 401 requires a WWW-Authenticate response header, which may or
> may not be appropriate depending on the authentication method(s) in use by
> the SET Recipient.
>
> [/richanna]
>
>
>
> - Section 5.1 talks about the SET Issuer being authorized to deliver the
> SET; should this not be the SET Transmitter?
>
> [richanna]
>
> Yes, this should say “SET Transmitter” instead of “SET Issuer”.
>
> [/richanna]
>
>
> - Section 5.4 on authenticating persisted SETs; Not sure if I understood
> this correctly, but if a SET Transmitter can send a SET that was issued
> by a different SET Issuer, how would the signature verification key be
> resolved to authenticate the SET? 5.4 talks about the SET *Transmitter*
> signing the SET, should this not be the SET *Issuer*? Or is this out of
> scope?
>
> [richanna]
>
> Technically, it could be either, e.g., if the issuer issued an unsigned,
> unencrypted SET and provided it to the transmitter, the transmitter could
> encrypt the SET (creating a nested JWT), and that would address the
> concerns laid out in 5.4. But on re-reading 5.4, I think this requirement
> should be applied to the *SET Recipient*, as they are the party that has
> the downstream authentication requirements necessitating this behavior. The
> last part of the last sentence of 5.4 should be changed to something like:
>
>
>
> …then the SET Recipient SHOULD ensure that such SETs have been signed in
> accordance with RFC7515 and/or encrypted using authenticated encryption in
> accordance with RFC7516.
>
>
>
> [/richanna]
>
>
> Nitpicks:
> - The sentence above the examples (e.g. in section 2.2) should always
> end with a colon ':' ("The following is ... a SET:"), or end with a
> period '.'. Don't care which, but looks nicer if it's the same
> everywhere. I think only 2.2 falls out of line.
>
> - The text above Figure 5 says "SET Receiver", should be "SET Recipient"
>
> Hope this helps to wrap it up to publication :)
>
>
> --
> Regards,
>
> Mark Dobrinic
> Software Engineer and Identity Specialist
> Curity AB
>
> [e-mail]
> www.curity.io
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>