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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <id-event-bounces@xxxxxxxx> On Behalf Of Phil Hunt
Sent: Tuesday, April 24, 2018 2:50 PM
To: Russ Housley <housley@xxxxxxxxxxxx>
Cc: draft-ietf-secevent-token.all@xxxxxxxx; Mike Jones <Michael.Jones@xxxxxxxxxxxxx>; ietf@xxxxxxxx; ID Events Mailing List <id-event@xxxxxxxx>; secdir@xxxxxxxx
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

phil.hunt@xxxxxxxxxx



On Apr 20, 2018, at 11:03 AM, Russ Housley <housley@xxxxxxxxxxxx> 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
Id-event@xxxxxxxx
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=

 


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux