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

[Mike Jones <[e-mail]>]

Hi Russ,

Not having heard back from you for a week, the editors decided to publish an updated draft https://tools.ietf.org/html/draft-ietf-secevent-token-10 that addresses your additional SecDir review comments in the manner proposed last week.  In particular, the revised text makes it clearer what requirements this specification is imposing on profiling specifications.  I hope the new text works for you.

                                                                Best wishes,
                                                                -- Mike

From: Mike Jones
Sent: Sunday, April 29, 2018 3:20 PM
To: Russ Housley <[e-mail]>
Cc: Phil Hunt <[e-mail]>; [e-mail]; [e-mail]; ID Events Mailing List <[e-mail]>; [e-mail]
Subject: RE: [Id-event] Secdir last call review of draft-ietf-secevent-token-09

Hi Russ,

I wanted to check back in.  Are you good with these changes to address your comment or do want to suggest that we take a different direction?

                                                       Thanks,
                                                       -- Mike

From: Id-event <[e-mail]<mailto:[e-mail]>> On Behalf Of Phil Hunt
Sent: Tuesday, April 24, 2018 2:50 PM
To: Russ Housley <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Mike Jones <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; ID Events Mailing List <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Id-event] Secdir last call review of draft-ietf-secevent-token-09

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]<mailto:[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]<mailto:[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=