Subject Identifiers for Security Event Tokens
draft-ietf-secevent-subject-identifiers-18

# Internet AD comments for draft-ietf-secevent-subject-identifiers-15
CC @ekline

## Comments

### S1

* IP addresses are listed as an example subject but section 3.2 does not
  have a dedicated format for them.  This is fine to exclude, of course,
  but I do think the inclusion here created an expectation there would be
  a format defined further down.

  ---

  IF a format is added for IP addresses and IF the member holding an
  address has string value type then the values should be REQUIRED to be
  in accordance with RFC 5952.

  (This kinda raises the issue of IP prefixes as well; again: it's fine with
   me to not specify anything about this in this document. :-)

Thank you for the work on this document.

Many thanks to Paul Kyzivat for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/3UoUPXy96ynW4msza41RfQqzsss/. I haven't seen any answer to Paul's review, which I think gives input for improvements and clarifications, so I would strongly encourage the authors to evaluate and respond to Paul's comments. Regarding Paul's 1st comment, I think that ship has sailed, so I would not insist on any change there.

Additionally, I was surprised to see the following statement in the expert guidelines:

> In the case where a request is rejected, the Expert Reviewer must provide the requesting party with a written statement expressing the reason for rejection, and be prepared to cite any sources of information that went into that decision.

Although I understand wanting to know the reasoning behind a rejection, I would not formulate this as a formal requirement on the experts. 

Francesca

Thanks for this very readable and thorough document. I have two minor comments. 

- the BCP 14 boilerplate is supposed to (normatively) reference RFC 8174 as well as RFC 2119.
- “contain a uri members” -> “contain a uri member” (agreement in number)

Thanks for addressing my DISCUSS issue.

For the record, I also supported Eric V's DISCUSS position.

The shepherd writeup says this about controversy in the working group:

  "No controversy beyond the normal."

Beyond this resulting in a cynical chuckle, I don't actually know whether I should be worried here.

The shepherd writeup also says:

  "Again, two of the authors have been recently active, while one has not been in touch for a long time."

This doesn't bode well for an easy AUTH48.  Should we consider moving that person to an Acknowledgments or Contributors section?

In Section 3.1:

  "E.g., While the email Identifier Format declares [...]"

I don't think you can start a sentence with "E.g.,"; I suggest changing that to "For example".

In Section 3.2.1 (and elsewhere):

  "Subject Identifiers in this format MUST contain a uri member whose value [...]"

Please put quotes around "uri" when it's used this way.  This isn't necessary when it's used as an acronym, but it should be quoted when it's a string literal.  I suggest the same for "url", "iss", "sub", and others; they otherwise look like misspelled or partial words.  "did" is even worse because it actually is an English word.

In Section 3.2.2:

  "The value of the email member SHOULD identify a mailbox to which email may be delivered [...]"

I'm curious about this constraint:

(a) If the goal is to have event-related content be reliably deliverable, why isn't this a MUST?

(b) If you leave it SHOULD, what interoperability concern specific to security events is created if I use an email address that's not actually deliverable?

In Section 3.2.4:

  "The Opaque Identifier Format describes a subject that is identified with a string with no semantics asserted beyond its usage as an identifier for the subject, such as a UUID or hash used as a surrogate identifier for a record in a database."

This is curious; since UUID has a specific standard format (and you could sync up with the UUIDREV working group if you want the cutting edge version), why not declare an Identifier Format for it explicitly?

In Section 8.1.2:

  "Contact information such as mailing address, email address, or phone number may also be provided."

A name alone probably isn't helpful to IANA.  I suggest changing "may" to "must".

My original DISCUSS position was:

I'd like to elevate something Paul observed in his comment to DISCUSS.  In Section 3.2.2.1:

  "When receiving an Email Subject Identifier, the recipient SHOULD use their implementation's canonicalization algorithm to resolve the email address to the same string used in their system."

This only applies if the domain portion of the email address is one that the local system considers to be a local address, correct?  That is, if I'm "example.com" but I get an email address of some other domain, I shouldn't be applying canonicalization at all, correct?

And to echo Paul's question: Why isn't the mail system doing the canonicalization?  Or is the goal here just to tell if two slightly different local addresses are (likely) referring to the same recipient for some aggregation purpose?

My general concern here is that now the events implementation has to exactly mirror whatever canonicalization the mail system is doing, which might not be known, or would require duplication of effort, or could allow for configuration drift, etc.  None of these are showstoppers, but it seems like more prose around this is probably a good idea if we want to go this route.

On Email Canonicalization:

        some providers treat the local part of the email address as
        case-insensitive as well, and consider "user@example.com",
        "User@example.com", and "USER@example.com" as the same email
        address.

"some" is an interesting word choice for "basically every implementation
currently deployed". More seriously, an example of where dots (".") are
optional would be a better example as there are actually servers which
do and which do not treat these as equivalent. Whereas for case sensitivity,
that ship sailed a decade ago. However, the overarching question is, why
should email canonicalization be done in the first place? Isn't that
better done at the receiver of the secevent? Or is that what is implied
in section 3.1 (as it doesnt talk about the producer or consumer at all)

In  8.2.1. Registry Contents, should the change controller be IETF, not IESG ?

NITS:

The layout in Section 4.1 makes it appear the Figure descriptions are above
the example instead of below it and makes things confusing. I'd recommend some
changes in whitespace / lines there.

8.1.3 Format Name: email is the only entry not using quotes (eg "email")

Thanks for addressing my DISCUSS points in https://mailarchive.ietf.org/arch/msg/id-event/xZOWRjkwpde0Mqlf6oi_Bj9LlQA/

Thanks to Roman to trigger my review of my previous ballot position, else I would still be sitting on it ;)

Usually, when a DISCUSS point is raised by an Area Director, this is to start a discussion (hence the name), but there was no discussion on my DISCUSS position. Unusual but OK.

Regards

-éric

", "a university".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool