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

["Richard Backman, Annabelle" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>
www.curity.io<http://www.curity.io>

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