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

From: Dick Hardt <[email-masked]>
Date: Thu, 11 Apr 2019 14:09:06 -0700

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 <[email-masked]>
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 ..")
>
> - Is the `description` field in the error response REQUIRED?
>
> - Is there a reason why the `authentication_failed` failure response
> should not return a HTTP/401 Unauthorized HTTP status code?
>
> - Section 5.1 talks about the SET Issuer being authorized to deliver the
> SET; should this not be the SET Transmitter?
>
> - 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?
>
> 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
>
> [email-masked]
> www.curity.io
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 12 Apr 2019 18:45:26 +0000

Thanks for the review, Mark! [richanna]Responses inline[/richanna].

--
Annabelle Richard Backman
AWS Identity

From: Id-event <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Thursday, April 11, 2019 at 2:09 PM
To: Mark Dobrinic <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] Review of draft-ietf-secevent-http-push-05

On Wed, Mar 27, 2019 at 3:55 AM Mark Dobrinic <[email-masked]<mailto:[email-masked]>> wrote:
Hi id-event,

[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]

[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]

[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]

[richanna]
Yes, this should say “SET Transmitter” instead of “SET Issuer”.
[/richanna]

[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:

--
Regards,

Mark Dobrinic

[email-masked]<mailto:[email-masked]>
www.curity.io<http://www.curity.io>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 14 Apr 2019 10:11:31 -0700

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=
[email-masked]> wrote:

> *From: *Id-event <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Thursday, April 11, 2019 at 2:09 PM
> *To: *Mark Dobrinic <[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, "Richard Backman, Annabelle"
> <[email-masked]>, SecEvent <[email-masked]>
> *Subject: *Re: [Id-event] Review of draft-ietf-secevent-http-push-05
>
>
>
> 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:
>
>
>
> 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]
>
>
> …the body [of the error response] MUST be a UTF-8 encoded JSON [RFC7159]
> object containing the following name/value pairs:
>
>
>
> 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]
>
>
>
> 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: