Re: [secdir] [Id-event] Secdir last call review of draft-ietf-secevent-token-09

[Phil Hunt <[e-mail]>]

Russ,

Here are proposed changes to address your questions about Section 3.  You’re right that this section is placing requirements on profiling specifications.  The changes made are intended to make this more explicit.  Please let us know if the updated text works for you, and if so, we’ll publish an updated draft using it.

Please see the wdiff text for section 3 below (also attached).

Thanks,

Phil & Mike

—wdiff for sec 3--
3.  Requirements for SET Profiles

   Profiling specifications of this specification define actual SETs to
   be used in particular use cases.  These profiling specifications
   define the syntax and semantics of SETs conforming to that SET
   profile and rules for validating those SETs.  Profiling
   specifications SHOULD define syntax, semantics, subject
   identification, and validation.

   Syntax
      The syntax defined by
   profiling specifications includes what claims of the SETs defined, including:

      Top-Level Claims
         Claims and event payload values placed at the JWT Claims Set. Examples are used
         claims defined by SETs utilizing the profile. JWT specification (see [RFC7519]), the
         SET specification, and by the profiling specification.

      Event Payload
         The JSON data structure contents and format, containing event-
         specific information, if any (see Section 1.2).

   Semantics
      Defining the semantics of the SET contents for SETs utilizing the
      profile is equally important.  Possibly most important is defining
      the procedures used to validate the SET issuer and to obtain the
      keys controlled by the issuer that were used for cryptographic
      operations used in the JWT representing the SET.  For instance,
      some profiles may define an algorithm for retrieving the SET
      issuer's keys that uses the "iss" claim value as its input.
      Likewise, if the profile allows (or requires) that the JWT be
      unsecured, the means by which the integrity of the JWT is ensured
      MUST be specified.

   Subject Identification
      Profiling specifications MUST define how the event subject is
      identified in the SET, as well as how to differentiate between the
      event subject's issuer and the SET issuer, if applicable.  It is
      NOT RECOMMENDED for profiling specifications to use the "sub"
      claim in cases in which the subject is not globally unique and has
      a different issuer from the SET itself.

   Validation
      Profiling specifications MUST clearly specify the steps that a
      recipient of a SET utilizing that profile MUST perform to validate
      that the SET is both syntactically and semantically valid.

      Among the syntax and semantics of SETs that a profiling
      specification may define is whether the value of the "events"
      claim may contain multiple members, and what processing
      instructions are employed in the single- and multiple-valued cases
      for SETs conforming to that profile.  Many valid choices are
      possible.  For instance, some profiles might allow multiple event
      identifiers to be present and specify that any that are not
      understood by recipients be ignored, thus enabling extensibility.
      Other profiles might allow multiple event identifiers to be
      present but require that all be understood if the SET is to be
      accepted.  Some profiles might require that only a single value be
      present.  All such choices are within the scope of profiling
      specifications to define.

   Profiling specifications MUST clearly specify the steps that a
   recipient of a SET utilizing that profile MUST perform to validate
   that the SET is both syntactically and semantically valid.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>


> On Apr 20, 2018, at 11:03 AM, Russ Housley <[e-mail]> wrote:
> 
> Reviewer: Russ Housley
> Review result: Has Issues
> 
> I reviewed this document as part of the Security Directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
> 
> Document: draft-ietf-secevent-token-09
> Reviewer: Russ Housley
> Review Date: 2018-04-20
> IETF LC End Date: unknown
> IESG Telechat date: 2018-05-10
> 
> Summary: Has Issues
> 
> Major Concerns
> 
> I do not understand the first paragraph of Section 3.  I made this
> comment on version -07, and some words were added, but I still do
> not understand this paragraph.  I think you are trying to impose some
> rules on future specifications that use SET to define events.  Let me
> ask a couple of questions that may help.  I understand that a
> profiling specification MUST specify the syntax and semantics for a
> collection of security event tokens, including the claims and payloads
> that are expected.  What MUST a profiling specification include?  What
> MUST a profiling specification NOT include?
> 
> 
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=hJFx-Z2ih18uUNCXosAjvygHqn2_K2mtNzqIej3Ah-c&s=28OWe42S0bg8Y2eo3VVzACeSYnzgiyyeXLl7tTu9i1Y&e=