Last Call Review of draft-ietf-secevent-subject-identifiers-14
review-ietf-secevent-subject-identifiers-14-artart-lc-kyzivat-2022-11-11-00

Reviewer: Paul Kyzivat
Review result: Ready with Issues

I am the assigned ARTART reviewer for this Internet-Draft.

Document: draft-ietf-secevent-subject-identifiers-14
Reviewer: Paul Kyzivat
Review Date: 2022-11-11
IETF LC End Date: 2022-11-17
IESG Telechat date: ?

Summary: Ready with Issues

Issues: 7
Nits:   0

1) ISSUE: Section 3, Collision-Resistant Names

The use of Collision-Resistant Names, as specified in the following:

    Every Identifier Format MUST have a unique name registered in the
    IANA "Security Event Identifier Formats" registry established by
    Section 8.1, or a Collision-Resistant Name as defined in [RFC7519].

is problematic. A collision-resistant name is only collision resistant 
with other names that follow the same rules. You can't mix names of 
constructed using independent rules and be confident there will be no 
collisions. To provide a safe way to use unregistered names you really 
need to choose a *particular* collision-resistant format. For instance, 
DNS names, or URNs.

I realize this approach was copied from RFC7519. The problem also exists 
there.

2) ISSUE: Section 3.2.1, "Account" definition

This section says that the specified URI must identify an *account*.
Is there any definition of "account" that would allow me to distinguish 
an uri that identifies one from a uri that doesn't? Needs clarification.

3) ISSUE: Section 3.2.2.1, Email Canonicalization

I see a potential issue with this:

    ... 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 algorithm may only be known to the email server implementation. The 
recipient of an email subject identifier may be distinct from the email 
server itself, and may deal with email addresses of multiple email 
servers. Is it reasonable to think it will necessarily know how to do 
this canonicalization?

This places some constraints on how email subject ids are used. It would 
be helpful for the document to discuss this.

4) ISSUE: Section 3.2.4, Opaque Identifier Format

I don't understand how opaque identifiers work. The sender and recipient 
must agree on the domain indexed by the identifier. How is that ensured?

Please clarify.

5) ISSUE: Section 3.2.5, Phone Number Identifier Format

This says the phone number is to be formatted according to E.164. But 
the example starts with "+" which is not used in E.164. The "+" is used 
for "global-number" in the tel: URI format (RFC3966). That is what is 
often used in IETF documents for representing E.164 numbers.

Be clear and consistent about which format you are using. If it is 
RFC3966, then you need to decide whether to also allow local-numbers and 
if so what that means.

6) ISSUE: Section 8.1.2, Change Controller

The definition and identification of Change Controller is vague. It 
isn't clear how to distinguish a valid value from an invalid one.

7) ISSUE: Section 8.1.2, Defining Document

The following wording for Defining Document is problematic:

       ... The definition MUST specify the name, format,
       and meaning of each member that may occur within a Subject
       Identifier of the defined format, as well as whether each member
       is optional, required, prohibited, or the circumstances under
       which the member may be optional, required, or prohibited.

This says that you can specify a member that *may occur* and then 
specify that it is *prohibited*. There seem to be two sub-cases here:

- a name that must *never* be used as a member name;

- a name that is only valid when certain conditions are met.

Some better wording would help.