Uploaded image for project: 'Technical Committee Administration'
  1. Technical Committee Administration
  2. TCADMIN-3008

Coordinate with SARIF TC in registering application/sarif+json media type with IANA

    Details

    • Type: Registration / Template Request
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:
      None
    • Environment:

      SARIF

    • Proposal:
      Hide

      Principal Contact = Luke Cartey, SARIF TC Co-Chair

      Show
      Principal Contact = Luke Cartey, SARIF TC Co-Chair

      Description

      TC members agreed in principle to a Media/MIME type of "application/sarif+json".

        Attachments

          Activity

          Hide
          robincover Robin Cover (Inactive) added a comment -

          1) See some initial details:

          https://lists.oasis-open.org/archives/sarif/201805/msg00170.html

          2) Larry Golding to describe the MIME type in the spec

          https://github.com/oasis-tcs/sarif-spec/issues/182

          Show
          robincover Robin Cover (Inactive) added a comment - 1) See some initial details: https://lists.oasis-open.org/archives/sarif/201805/msg00170.html 2) Larry Golding to describe the MIME type in the spec https://github.com/oasis-tcs/sarif-spec/issues/182
          Hide
          robincover Robin Cover (Inactive) added a comment -

          On  "application/sarif+json"

          I recommend that the SARIF TC members drafting and reviewing the proposal make contact with the CTI TC [Bret Jordan, lead] in July 2018 (or later) to obtain information about the two +json media type regiatrations worked out there, in communication with the IANA designated experts. In queue June 2018: application/taxii+json and application/stix+json

          https://www.ietf.org/mail-archive/web/media-types/current/msg00973.html
          https://www.ietf.org/mail-archive/web/media-types/current/msg00974.html
          https://www.ietf.org/mail-archive/web/media-types/current/msg00975.html

          Coordinate with CTI TC in registering stix/taxii +json media types with IANA
          https://issues.oasis-open.org/browse/TCADMIN-2995

          IANA input on security considerations for media type registrations

          https://tools.ietf.org/html/rfc6838#section-4.6

          [Designated IESG Expert Reviewer has clarified]

          ... in addition to referencing any security considerations
          of underlying formats each type must elaborate on its own issues. In
          particular, you must:

          (1) State whether or not the media type contains active or executable
          content. If the media type does contain executable content explain
          what measures have been taken to insure that it can be executed
          safely, e.g. a sandbox, safe operation set, signed content, etc.

          (2) State whether or not the information contained in the media type
          needs privacy or integrity services.

          (3) If the answer to (2) is yes, elaborate on any privacy or integrity
          services the media type itself provides, or if it doesn't provide such
          services, explain how they should be provided externally, e.g., through
          the use of SSL/TLS.

          "Media Type Specifications and Registration Procedures"
          https://tools.ietf.org/html/rfc6838#section-4.6

          4.6. Security Requirements

          An analysis of security issues MUST be done for all types registered
          in the standards tree. A similar analysis for media types registered
          in the vendor or personal trees is encouraged but not required.
          However, regardless of what security analysis has or has not been
          done, all descriptions of security issues MUST be as accurate as
          possible regardless of registration tree. In particular, the
          security considerations MUST NOT state that there are "no security
          issues associated with this type". Security considerations for types
          in the vendor or personal tree MAY say that "the security issues
          associated with this type have not been assessed".

          There is absolutely no requirement that media types registered in any
          tree be secure or completely free from risks. Nevertheless, all
          known security risks MUST be identified in the registration of a
          media type, again regardless of registration tree.

          The security considerations section of all registrations is subject
          to continuing evaluation and modification, and in particular MAY be
          extended by use of the "comments on media types" mechanism described
          in Section 5.4 below.

          Some of the issues that need to be examined and described in a
          security analysis of a media type are:

          o Complex media types may include provisions for directives that
          institute actions on a recipient's files or other resources. In
          many cases, provision is made for originators to specify arbitrary
          actions in an unrestricted fashion that may then have devastating
          effects. See the registration of the application/postscript media
          type in [RFC2046] for an example of such directives and how they
          can be described in a media type registration.

          o Any security analysis MUST state whether or not they employ such
          "active content"; if they do, they MUST state what steps have been
          taken, or MUST be taken by applications of the media type, to
          protect users of the media type from harm.

          o Complex media types may include provisions for directives that
          institute actions that, while not directly harmful to the
          recipient, may result in disclosure of information that either
          facilitates a subsequent attack or else violates a recipient's
          privacy in some way. Again, the registration of the application/
          postscript media type illustrates how such directives can be
          handled.

          o A media type that employs compression may provide an opportunity
          for sending a small amount of data that, when received and
          evaluated, expands enormously to consume all of the recipient's
          resources. All media types SHOULD state whether or not they
          employ compression; if they do, they SHOULD discuss what steps
          need to be taken to avoid such attacks.

          o A media type might be targeted for applications that require some
          sort of security assurance but don't provide the necessary
          security mechanisms themselves. For example, a media type could
          be defined for storage of sensitive medical information that in
          turn requires external confidentiality and integrity protection
          services, or which is designed for use only within a secure
          environment. Types SHOULD always document whether or not they
          need such services in their security considerations.

          Show
          robincover Robin Cover (Inactive) added a comment - On  "application/sarif+json" I recommend that the SARIF TC members drafting and reviewing the proposal make contact with the CTI TC [Bret Jordan, lead] in July 2018 (or later) to obtain information about the two +json media type regiatrations worked out there, in communication with the IANA designated experts. In queue June 2018: application/taxii+json and application/stix+json https://www.ietf.org/mail-archive/web/media-types/current/msg00973.html https://www.ietf.org/mail-archive/web/media-types/current/msg00974.html https://www.ietf.org/mail-archive/web/media-types/current/msg00975.html Coordinate with CTI TC in registering stix/taxii +json media types with IANA https://issues.oasis-open.org/browse/TCADMIN-2995 IANA input on security considerations for media type registrations https://tools.ietf.org/html/rfc6838#section-4.6 [Designated IESG Expert Reviewer has clarified] ... in addition to referencing any security considerations of underlying formats each type must elaborate on its own issues. In particular, you must: (1) State whether or not the media type contains active or executable content. If the media type does contain executable content explain what measures have been taken to insure that it can be executed safely, e.g. a sandbox, safe operation set, signed content, etc. (2) State whether or not the information contained in the media type needs privacy or integrity services. (3) If the answer to (2) is yes, elaborate on any privacy or integrity services the media type itself provides, or if it doesn't provide such services, explain how they should be provided externally, e.g., through the use of SSL/TLS. – "Media Type Specifications and Registration Procedures" https://tools.ietf.org/html/rfc6838#section-4.6 4.6. Security Requirements An analysis of security issues MUST be done for all types registered in the standards tree. A similar analysis for media types registered in the vendor or personal trees is encouraged but not required. However, regardless of what security analysis has or has not been done, all descriptions of security issues MUST be as accurate as possible regardless of registration tree. In particular, the security considerations MUST NOT state that there are "no security issues associated with this type". Security considerations for types in the vendor or personal tree MAY say that "the security issues associated with this type have not been assessed". There is absolutely no requirement that media types registered in any tree be secure or completely free from risks. Nevertheless, all known security risks MUST be identified in the registration of a media type, again regardless of registration tree. The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on media types" mechanism described in Section 5.4 below. Some of the issues that need to be examined and described in a security analysis of a media type are: o Complex media types may include provisions for directives that institute actions on a recipient's files or other resources. In many cases, provision is made for originators to specify arbitrary actions in an unrestricted fashion that may then have devastating effects. See the registration of the application/postscript media type in [RFC2046] for an example of such directives and how they can be described in a media type registration. o Any security analysis MUST state whether or not they employ such "active content"; if they do, they MUST state what steps have been taken, or MUST be taken by applications of the media type, to protect users of the media type from harm. o Complex media types may include provisions for directives that institute actions that, while not directly harmful to the recipient, may result in disclosure of information that either facilitates a subsequent attack or else violates a recipient's privacy in some way. Again, the registration of the application/ postscript media type illustrates how such directives can be handled. o A media type that employs compression may provide an opportunity for sending a small amount of data that, when received and evaluated, expands enormously to consume all of the recipient's resources. All media types SHOULD state whether or not they employ compression; if they do, they SHOULD discuss what steps need to be taken to avoid such attacks. o A media type might be targeted for applications that require some sort of security assurance but don't provide the necessary security mechanisms themselves. For example, a media type could be defined for storage of sensitive medical information that in turn requires external confidentiality and integrity protection services, or which is designed for use only within a secure environment. Types SHOULD always document whether or not they need such services in their security considerations.
          Hide
          robincover Robin Cover (Inactive) added a comment -

           

          https://lists.oasis-open.org/archives/sarif/201806/msg00081.html

          https://lists.oasis-open.org/archives/sarif/201806/msg00082.html

          Thanks Robin.

          I will draft the text of the "Security Considerations" portion of the proposal and push it to the Documents folder in our repo.
          [ https://github.com/oasis-tcs/sarif-spec/tree/master/Documents ]

          Larry

          Show
          robincover Robin Cover (Inactive) added a comment -   https://lists.oasis-open.org/archives/sarif/201806/msg00081.html https://lists.oasis-open.org/archives/sarif/201806/msg00082.html Thanks Robin. I will draft the text of the "Security Considerations" portion of the proposal and push it to the Documents folder in our repo. [ https://github.com/oasis-tcs/sarif-spec/tree/master/Documents ] Larry
          Hide
          chet-oasis Chet Ensign added a comment -

          Sent email to Luke and David letting them know that I am taking over the work on this ticket.

          Show
          chet-oasis Chet Ensign added a comment - Sent email to Luke and David letting them know that I am taking over the work on this ticket.
          Hide
          chet-oasis Chet Ensign added a comment -

          Reply from David:

          Thanks, Chet. Sorry to hear that we're losing Robin.

          Luke, would you please take the lead in making sure we jump through all the right hoops for this? Larry is drafting the document, and that will probably be most of the work.

          David

          Show
          chet-oasis Chet Ensign added a comment - Reply from David: Thanks, Chet. Sorry to hear that we're losing Robin. Luke, would you please take the lead in making sure we jump through all the right hoops for this? Larry is drafting the document, and that will probably be most of the work. David
          Hide
          chet-oasis Chet Ensign added a comment -

          There has been no further action on this task. I am closing the ticket. If action resumes, we can reopen or start fresh.

          Show
          chet-oasis Chet Ensign added a comment - There has been no further action on this task. I am closing the ticket. If action resumes, we can reopen or start fresh.
          Hide
          chet-oasis Chet Ensign added a comment -

          Larry Golding emailed on March 9th to pick up the discussion:

          Larry Golding (Myriad Consulting Inc)
          Attachments
          Sat, Mar 7, 5:15 PM (2 days ago)
          to me, Michael, David, luke

          Hello Chet,

          I'm following up on an issue we have in our repo, https://github.com/oasis-tcs/sarif-spec/issues/182: "Register SARIF MIME type and sarif URI schema".

          We want to register:

          • application/sarif+json as the MIME type for SARIF log files
          • application/sarif-fragment+json as the MIME type for a fragment of a SARIF log file (for example, a single result object seen in isolation from any log file).
          • sarif: as a URI schema for locating an object within a SARIF log file

          The GitHub issue originally anticipated that we'd register these items and then update the spec to refer to them, but that ship has sailed (we're ready to go to Call for Consent as soon as our current ballot closes), so now we'll be happy just to get the registrations done.

          There's a comment<https://github.com/oasis-tcs/sarif-spec/issues/182#issuecomment-393947270> in the GitHub issue where Robin Cover acknowledges receipt of an email requesting OASIS to coordinate the process, but I can't find that email. How should we proceed?

          Thanks,
          Larry

          Show
          chet-oasis Chet Ensign added a comment - Larry Golding emailed on March 9th to pick up the discussion: Larry Golding (Myriad Consulting Inc) Attachments Sat, Mar 7, 5:15 PM (2 days ago) to me, Michael, David, luke Hello Chet, I'm following up on an issue we have in our repo, https://github.com/oasis-tcs/sarif-spec/issues/182: "Register SARIF MIME type and sarif URI schema". We want to register: application/sarif+json as the MIME type for SARIF log files application/sarif-fragment+json as the MIME type for a fragment of a SARIF log file (for example, a single result object seen in isolation from any log file). sarif: as a URI schema for locating an object within a SARIF log file The GitHub issue originally anticipated that we'd register these items and then update the spec to refer to them, but that ship has sailed (we're ready to go to Call for Consent as soon as our current ballot closes), so now we'll be happy just to get the registrations done. There's a comment< https://github.com/oasis-tcs/sarif-spec/issues/182#issuecomment-393947270 > in the GitHub issue where Robin Cover acknowledges receipt of an email requesting OASIS to coordinate the process, but I can't find that email. How should we proceed? Thanks, Larry
          Hide
          chet-oasis Chet Ensign added a comment -
          • They recommend reading:
            RFC 2045 - MIME formats and encodings
            RFC 2046 - Definition of media types
            RFC 2077 - Model top-level media type
            RFC 7303 - XML Media Types
            RFC 6657 - Update to MIME regarding "charset" Parameter Handling in Textual Media Types
            RFC 6838 - Media type specifications and registration procedures
          Show
          chet-oasis Chet Ensign added a comment - Application form at https://www.iana.org/form/media-types They recommend reading: RFC 2045 - MIME formats and encodings RFC 2046 - Definition of media types RFC 2077 - Model top-level media type RFC 7303 - XML Media Types RFC 6657 - Update to MIME regarding "charset" Parameter Handling in Textual Media Types RFC 6838 - Media type specifications and registration procedures
          Hide
          chet-oasis Chet Ensign added a comment -

          Sent email to Larry, pointing to RFC 6838, in particular, the application procedures in section 5 and the template at 5.6 -> https://tools.ietf.org/html/rfc6838#page-22.

          Recommended doing this as a separate CS (similar to LegalDocML TC -> http://docs.oasis-open.org/legaldocml/akn-media/v1.0/akn-media-v1.0.html) so that call for consent for SARIF COS can proceed without delay. Approval as a CS should be sufficient to qualify for IANA purposes, particularly since the media type will point to the spec.

          Show
          chet-oasis Chet Ensign added a comment - Sent email to Larry, pointing to RFC 6838, in particular, the application procedures in section 5 and the template at 5.6 -> https://tools.ietf.org/html/rfc6838#page-22 . Recommended doing this as a separate CS (similar to LegalDocML TC -> http://docs.oasis-open.org/legaldocml/akn-media/v1.0/akn-media-v1.0.html ) so that call for consent for SARIF COS can proceed without delay. Approval as a CS should be sufficient to qualify for IANA purposes, particularly since the media type will point to the spec.
          Hide
          chet-oasis Chet Ensign added a comment -
          Show
          chet-oasis Chet Ensign added a comment - Larry sent link to draft registration: https://github.com/oasis-tcs/sarif-spec/blob/master/IanaRegistrations/sarif-media-type.txt
          Hide
          chet-oasis Chet Ensign added a comment - - edited

          Note: if no response on media-types@ by Apr 23, submit request to iana.org

          to: media-types@iana.org, cc: Mike and Larry

          subject: Notice of request for media-type registration: application/sarif+json

          Members of the OASIS Static Analysis Results Interchange Format (SARIF) Technical Committee wish to register a media type
          associated with the SARIF Version 2.1.0 OASIS Standard. We post the registration request form to the list for review prior to submission.

          I am the administrative contact for OASIS for IANA registration requests. The technical contacts for this request are Michael Fanning (mikefan@microsoft.com) and Laurence Golding (v-lgold@microsoft.com). They are tasked by the OASIS SARIF TC to provide any information you may have.

          Thank you in advance for your comments and feedback.

          /chet ensign
          OASIS Open, Inc.

          IETF RFC6838 Section 5.6. Registration Template
          https://tools.ietf.org/html/rfc6838#section-5.6

          Type name: application

          Subtype name: sarif+json

          Required parameters: N/A

          Optional parameters: N/A

          Encoding considerations: UTF8 only

          Security considerations:

          • The use of absolute paths in analysis result location URIs might reveal sensitive information about the machine on which the scan was performed.
          • The use of the hostname component in analysis result location URI might reveal the network location of the machine on which the scan was performed.
          • The use of raw HTML in message strings expressed in Markdown might allow arbitrary code execution (for example, through javascript: links).
          • The use of deeply nested constructs in Markdown message strings might lead to stack overflow in some Markdown implementations.
          • Certain properties of the SARIF object model might reveal information about the machine on which a scan was run. (The specification allows such properties to be omitted or "redacted".)
          • Certain properties of the SARIF object model (such as the command line that invoked the analysis tool) can contain arbitrary commands which might damage a machine on which they are run.

          Interoperability considerations: N/A

          Published specification:

          Static Analysis Results Interchange Format (SARIF) Version 2.1.0. Edited by Michael C. Fanning and Laurence J. Golding. 27 March 2020. OASIS Standard. https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html. Latest stage: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html.

          Applications that use this media type:

          The following list is not exhaustive:

          • Static analysis tools
          • Static analysis results visualization tools (viewers)
          • Bug filing tools
          • Defect databases
          • Compliance systems

          Fragment identifier considerations: N/A

          Additional information:

          Deprecated alias names for this type: N/A
          Magic number(s): N/A
          File extension(s): .sarif, .sarif.json
          Macintosh file type code(s): N/A

          Person & email address to contact for further information: Michael C. Fanning (mikefan@microsoft.com), Laurence J. Golding (v-lgold@microsoft.com), and Chet Ensign (chet.ensign@oasis-open.org)

          Intended usage: LIMITED USE

          Restrictions on usage: N/A

          Author:

          OASIS Static Analysis Results Interchange Format (SARIF) TC (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif)

          Change controller:

          OASIS Open (https://www.oasis-open.org/)

          Provisional registration? (standards tree only): No

          Show
          chet-oasis Chet Ensign added a comment - - edited Note: if no response on media-types@ by Apr 23, submit request to iana.org to: media-types@iana.org, cc: Mike and Larry subject: Notice of request for media-type registration: application/sarif+json Members of the OASIS Static Analysis Results Interchange Format (SARIF) Technical Committee wish to register a media type associated with the SARIF Version 2.1.0 OASIS Standard. We post the registration request form to the list for review prior to submission. I am the administrative contact for OASIS for IANA registration requests. The technical contacts for this request are Michael Fanning (mikefan@microsoft.com) and Laurence Golding (v-lgold@microsoft.com). They are tasked by the OASIS SARIF TC to provide any information you may have. Thank you in advance for your comments and feedback. /chet ensign OASIS Open, Inc. IETF RFC6838 Section 5.6. Registration Template https://tools.ietf.org/html/rfc6838#section-5.6 — Type name: application Subtype name: sarif+json Required parameters: N/A Optional parameters: N/A Encoding considerations: UTF8 only Security considerations: The use of absolute paths in analysis result location URIs might reveal sensitive information about the machine on which the scan was performed. The use of the hostname component in analysis result location URI might reveal the network location of the machine on which the scan was performed. The use of raw HTML in message strings expressed in Markdown might allow arbitrary code execution (for example, through javascript: links). The use of deeply nested constructs in Markdown message strings might lead to stack overflow in some Markdown implementations. Certain properties of the SARIF object model might reveal information about the machine on which a scan was run. (The specification allows such properties to be omitted or "redacted".) Certain properties of the SARIF object model (such as the command line that invoked the analysis tool) can contain arbitrary commands which might damage a machine on which they are run. Interoperability considerations: N/A Published specification: Static Analysis Results Interchange Format (SARIF) Version 2.1.0. Edited by Michael C. Fanning and Laurence J. Golding. 27 March 2020. OASIS Standard. https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html . Latest stage: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html . Applications that use this media type: The following list is not exhaustive: Static analysis tools Static analysis results visualization tools (viewers) Bug filing tools Defect databases Compliance systems Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .sarif, .sarif.json Macintosh file type code(s): N/A Person & email address to contact for further information: Michael C. Fanning (mikefan@microsoft.com), Laurence J. Golding (v-lgold@microsoft.com), and Chet Ensign (chet.ensign@oasis-open.org) Intended usage: LIMITED USE Restrictions on usage: N/A Author: OASIS Static Analysis Results Interchange Format (SARIF) TC ( https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif ) Change controller: OASIS Open ( https://www.oasis-open.org/ ) Provisional registration? (standards tree only): No
          Hide
          chet-oasis Chet Ensign added a comment -

          no comment received. the request was sent to iana@iana.org with cc to Mike and Larry:

          subject: Registration request for media-type application/sarif+json

          Members of the OASIS Static Analysis Results Interchange Format (SARIF) Technical Committee wish to register a media type associated with the SARIF Version 2.1.0 OASIS Standard.

          This request was sent to the media-types mailing list for comment on 09 April 2020 (see: https://mailarchive.ietf.org/arch/msg/media-types/dYcLl3hit3UIfVxyvmSBROq_o0A/). No comments were received.

          Questions on the specification and this request can be submitted to Chet Ensign (chet.ensign@oasis-open.org) or, for technical details, to Michael Fanning (mikefan@microsoft.com) and Laurence Golding (v-lgold@microsoft.com). They are tasked by the OASIS SARIF TC to provide any information you request.

          Best regards,

          /chet ensign
          OASIS Open, Inc.

          Type name: application

          Subtype name: sarif+json

          Required parameters: N/A

          Optional parameters: N/A

          Encoding considerations: UTF8 only

          Security considerations:

          • The use of absolute paths in analysis result location URIs might reveal sensitive information about the machine on which the scan was performed.
          • The use of the hostname component in analysis result location URI might reveal the network location of the machine on which the scan was performed.
          • The use of raw HTML in message strings expressed in Markdown might allow arbitrary code execution (for example, through javascript: links).
          • The use of deeply nested constructs in Markdown message strings might lead to stack overflow in some Markdown implementations.
          • Certain properties of the SARIF object model might reveal information about the machine on which a scan was run. (The specification allows such properties to be omitted or "redacted".)
          • Certain properties of the SARIF object model (such as the command line that invoked the analysis tool) can contain arbitrary commands which might damage a machine on which they are run.

          Interoperability considerations: N/A

          Published specification:

          Static Analysis Results Interchange Format (SARIF) Version 2.1.0. Edited by Michael C. Fanning and Laurence J. Golding. 27 March 2020. OASIS Standard. https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html. Latest stage: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html.

          Applications that use this media type:

          The following list is not exhaustive:

          • Static analysis tools
          • Static analysis results visualization tools (viewers)
          • Bug filing tools
          • Defect databases
          • Compliance systems

          Fragment identifier considerations: N/A

          Additional information:

          Deprecated alias names for this type: N/A
          Magic number(s): N/A
          File extension(s): .sarif, .sarif.json
          Macintosh file type code(s): N/A

          Person & email address to contact for further information:

          Michael C. Fanning (mikefan@microsoft.com), Laurence J. Golding (
          v-lgold@microsoft.com), and Chet Ensign (chet.ensign@oasis-open.org)

          Intended usage: LIMITED USE

          Restrictions on usage: N/A

          Author:

          OASIS Static Analysis Results Interchange Format (SARIF) TC (
          https://www.oasis-open.org/committees/sarif/)

          Change controller:

          OASIS Open (https://www.oasis-open.org/)

          Provisional registration? (standards tree only): No

          /chet
          ----------------
          Chet Ensign
          Chief Technical Community Steward
          OASIS: Advancing open source & open standards for the information society
          http://www.oasis-open.org

          Mobile: +1 201-341-1393

          Show
          chet-oasis Chet Ensign added a comment - no comment received. the request was sent to iana@iana.org with cc to Mike and Larry: subject: Registration request for media-type application/sarif+json Members of the OASIS Static Analysis Results Interchange Format (SARIF) Technical Committee wish to register a media type associated with the SARIF Version 2.1.0 OASIS Standard. This request was sent to the media-types mailing list for comment on 09 April 2020 (see: https://mailarchive.ietf.org/arch/msg/media-types/dYcLl3hit3UIfVxyvmSBROq_o0A/ ). No comments were received. Questions on the specification and this request can be submitted to Chet Ensign (chet.ensign@oasis-open.org) or, for technical details, to Michael Fanning (mikefan@microsoft.com) and Laurence Golding (v-lgold@microsoft.com). They are tasked by the OASIS SARIF TC to provide any information you request. Best regards, /chet ensign OASIS Open, Inc. — Type name: application Subtype name: sarif+json Required parameters: N/A Optional parameters: N/A Encoding considerations: UTF8 only Security considerations: The use of absolute paths in analysis result location URIs might reveal sensitive information about the machine on which the scan was performed. The use of the hostname component in analysis result location URI might reveal the network location of the machine on which the scan was performed. The use of raw HTML in message strings expressed in Markdown might allow arbitrary code execution (for example, through javascript: links). The use of deeply nested constructs in Markdown message strings might lead to stack overflow in some Markdown implementations. Certain properties of the SARIF object model might reveal information about the machine on which a scan was run. (The specification allows such properties to be omitted or "redacted".) Certain properties of the SARIF object model (such as the command line that invoked the analysis tool) can contain arbitrary commands which might damage a machine on which they are run. Interoperability considerations: N/A Published specification: Static Analysis Results Interchange Format (SARIF) Version 2.1.0. Edited by Michael C. Fanning and Laurence J. Golding. 27 March 2020. OASIS Standard. https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html . Latest stage: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html . Applications that use this media type: The following list is not exhaustive: Static analysis tools Static analysis results visualization tools (viewers) Bug filing tools Defect databases Compliance systems Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .sarif, .sarif.json Macintosh file type code(s): N/A Person & email address to contact for further information: Michael C. Fanning (mikefan@microsoft.com), Laurence J. Golding ( v-lgold@microsoft.com), and Chet Ensign (chet.ensign@oasis-open.org) Intended usage: LIMITED USE Restrictions on usage: N/A Author: OASIS Static Analysis Results Interchange Format (SARIF) TC ( https://www.oasis-open.org/committees/sarif/ ) Change controller: OASIS Open ( https://www.oasis-open.org/ ) Provisional registration? (standards tree only): No – /chet ---------------- Chet Ensign Chief Technical Community Steward OASIS: Advancing open source & open standards for the information society http://www.oasis-open.org Mobile: +1 201-341-1393
          Hide
          chet-oasis Chet Ensign added a comment -

          Response received from iana support
          :
          IANA #1168764 AutoReply: Registration request for media-type application/sarif+json

          To whom it may concern:

          This is an automatically generated message to notify you that we have
          received your request, and it has been recorded in our ticketing
          system with a reference number of 1168764.

          There is no need to reply to this message right now. IANA staff will review
          your message and reply to your inquiry within three (3) business days.

          If this message is in reply to a previously submitted ticket, it is
          possible that the previous ticket has been marked as closed. As we
          review this ticket, we will also review previous correspondence and
          take appropriate action.

          To expedite processing, and ensure our staff can view the full history
          of this request, please make sure you include the follow exact text in
          the subject line of all future correspondence on this issue:

          IANA #1168764

          You can also simply reply to this message, as this tag is already in
          the subject line.

          Thank you,

          IANA Services
          iana-questions@iana.org
          PTI

          Show
          chet-oasis Chet Ensign added a comment - Response received from iana support : IANA #1168764 AutoReply: Registration request for media-type application/sarif+json To whom it may concern: This is an automatically generated message to notify you that we have received your request, and it has been recorded in our ticketing system with a reference number of 1168764. There is no need to reply to this message right now. IANA staff will review your message and reply to your inquiry within three (3) business days. If this message is in reply to a previously submitted ticket, it is possible that the previous ticket has been marked as closed. As we review this ticket, we will also review previous correspondence and take appropriate action. To expedite processing, and ensure our staff can view the full history of this request, please make sure you include the follow exact text in the subject line of all future correspondence on this issue: IANA #1168764 You can also simply reply to this message, as this tag is already in the subject line. Thank you, IANA Services iana-questions@iana.org PTI
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to notify us that the request was sent to the expert:

          Amanda Baber via RT via icann.org
          Thu, Apr 23, 8:25 PM (13 hours ago)
          to michael.fanning, me, v-lgold

          Hi Chet, Michael, Larry,

          I'm just writing to confirm that this request has been sent to the IESG-designated media type experts for review.

          Best regards,

          Amanda Baber
          Lead IANA Services Specialist

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to notify us that the request was sent to the expert: Amanda Baber via RT via icann.org Thu, Apr 23, 8:25 PM (13 hours ago) to michael.fanning, me, v-lgold Hi Chet, Michael, Larry, I'm just writing to confirm that this request has been sent to the IESG-designated media type experts for review. Best regards, Amanda Baber Lead IANA Services Specialist
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to notify us that the request is still with the expert:

          Hi all,

          I'm just writing to confirm that this request is still with the reviewers. No action is required on your part.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to notify us that the request is still with the expert: Hi all, I'm just writing to confirm that this request is still with the reviewers. No action is required on your part.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote on May 11th that the request is still with the reviewer and no action is needed from us.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote on May 11th that the request is still with the reviewer and no action is needed from us.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote again to let us know that the request is with the reviewer and no action is needed.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote again to let us know that the request is with the reviewer and no action is needed.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote again to let us know that the request is with the reviewer and no action is needed.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote again to let us know that the request is with the reviewer and no action is needed.
          Hide
          chet-oasis Chet Ensign added a comment -

          michelle cotton wrote to confirm still with reviewers

          Hello,

          I'm just writing to confirm that this request is still with the reviewers. No action is required on your part.

          Best regards,

          Michelle Cotton
          Protocol Parameters Engagement Sr. Manager
          IANA Services

          Show
          chet-oasis Chet Ensign added a comment - michelle cotton wrote to confirm still with reviewers Hello, I'm just writing to confirm that this request is still with the reviewers. No action is required on your part. Best regards, Michelle Cotton Protocol Parameters Engagement Sr. Manager IANA Services
          Hide
          chet-oasis Chet Ensign added a comment -

          Response received from IANA. i pinged Michael and Larry and asked them how they'd like to proceed.

          =====

          Review:

          FWIW, the main difficulty here is separating the security considerations of
          static analysis tools themselves - which are outside the scope of this
          registration - from those of this specific format.

          Lots of notes below.

          > Members of the OASIS Static Analysis Results Interchange Format (SARIF)
          > Technical Committee wish to register a media type associated with the SARIF
          > Version 2.1.0 OASIS Standard.

          > This request was sent to the media-types mailing list for comment on 09 April
          > 2020 (see: https://mailarchive.ietf.org/arch/msg/media-types/dYcLl3hit3UIfVxyvmSBROq_o0A/).
          > No comments were received.

          > Questions on the specification and this request can be submitted to Chet Ensign (chet.ensign@oasis-open.org) or, for technical details, to Michael Fanning (mikefan@microsoft.com) and Laurence Golding (v-lgold@microsoft.com). They are tasked by the OASIS SARIF TC to provide any information you request.

          > Best regards,

          > /chet ensign
          > OASIS Open, Inc.

          > —

          > Type name: application

          > Subtype name: sarif+json

          > Required parameters: N/A

          > Optional parameters: N/A

          > Encoding considerations: UTF8 only

          This needs to begin by saying "binary". The note about being UTF-8 only should
          appear after that.

          > Security considerations:

          Since Sarif files are in JSON format, they inherit the security issues
          of JSON. There should be a note here to that effect.

          The specific points listed below are very good, however, this needs to start
          with a general discussion of the security considerations of the format as a
          whole, which necessarily leads to some discussion of privacy and integrity.
          Something like:

          The Sarif provides the means to capture the results of static analysis tools.
          Such analysis may include information about software vulnerabilities. As such,
          Sarif file content may be extremely sensitive, requiring external privacy
          and integrity protection.

          Even when the analysis results themselves are not sensitive, Satif files
          may have other security issues:

          And then move on to your list.

          > - The use of absolute paths in analysis result location URIs might reveal
          > sensitive information about the machine on which the scan was performed.

          > - The use of the hostname component in analysis result location URI might
          > reveal the network location of the machine on which the scan was performed.

          Run information can also be present, and it can include details about when
          analysis runs are performed. An attacker might be able to leverage this to
          avoid getting caught doing something naughty...

          Similarly, information about analysis processing failing with an error might be
          used to know when it is safe to make some kind of change. It might even be
          leveraged to attack the analysis process itself.

          > - The use of raw HTML in message strings expressed in Markdown might allow
          > arbitrary code execution (for example, through javascript: links).

          > - The use of deeply nested constructs in Markdown message strings might lead
          > to stack overflow in some Markdown implementations.

          This seems a little specific. It might be useful to mention that there may
          be other Markdown issues that could be exploited.

          > - Certain properties of the SARIF object model might reveal information about
          > the machine on which a scan was run. (The specification allows such properties
          > to be omitted or "redacted".)

          > - Certain properties of the SARIF object model (such as the command line that
          > invoked the analysis tool) can contain arbitrary commands which might damage a
          > machine on which they are run.

          There doesn't seem to be any discussion of artifacts, file references, or web
          responses here. I suggest something like:

          Sarif files can contain artifacts, references to external artifacts,
          file references, and web responses. Such content can be of any type, and may
          include compressed material, with all its associated issues.

          Not very well worded, but you get the idea.

          > Interoperability considerations: N/A

          > Published specification:

          > Static Analysis Results Interchange Format (SARIF) Version 2.1.0. Edited by
          > Michael C. Fanning and Laurence J. Golding. 27 March 2020. OASIS Standard.
          > https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html. Latest
          > stage: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html.

          > Applications that use this media type:

          > The following list is not exhaustive:

          > - Static analysis tools
          > - Static analysis results visualization tools (viewers)
          > - Bug filing tools
          > - Defect databases
          > - Compliance systems

          > Fragment identifier considerations: N/A

          > Additional information:

          > Deprecated alias names for this type: N/A
          > Magic number(s): N/A
          > File extension(s): .sarif, .sarif.json
          > Macintosh file type code(s): N/A

          > Person & email address to contact for further information:

          > Michael C. Fanning (mikefan@microsoft.com), Laurence J. Golding (
          > v-lgold@microsoft.com), and Chet Ensign (chet.ensign@oasis-open.org)

          > Intended usage: LIMITED USE

          I can understand why you'd say LIMITED USE here - only certain very specific
          tools would ever use this format - but generally speaking when registrations
          say "LIMITED USE" they mean that the format is intended for general use within
          it's realm of applicabiity. While this is entirely your call, I think
          "COMMON" is actually more appropriate.

          > Restrictions on usage: N/A

          > Author:

          > OASIS Static Analysis Results Interchange Format (SARIF) TC (
          > https://www.oasis-open.org/committees/sarif/)

          > Change controller:

          > OASIS Open (https://www.oasis-open.org/)

          > Provisional registration? (standards tree only): No

          =====

          Show
          chet-oasis Chet Ensign added a comment - Response received from IANA. i pinged Michael and Larry and asked them how they'd like to proceed. ===== Review: FWIW, the main difficulty here is separating the security considerations of static analysis tools themselves - which are outside the scope of this registration - from those of this specific format. Lots of notes below. > Members of the OASIS Static Analysis Results Interchange Format (SARIF) > Technical Committee wish to register a media type associated with the SARIF > Version 2.1.0 OASIS Standard. > This request was sent to the media-types mailing list for comment on 09 April > 2020 (see: https://mailarchive.ietf.org/arch/msg/media-types/dYcLl3hit3UIfVxyvmSBROq_o0A/ ). > No comments were received. > Questions on the specification and this request can be submitted to Chet Ensign (chet.ensign@oasis-open.org) or, for technical details, to Michael Fanning (mikefan@microsoft.com) and Laurence Golding (v-lgold@microsoft.com). They are tasked by the OASIS SARIF TC to provide any information you request. > Best regards, > /chet ensign > OASIS Open, Inc. > — > Type name: application > Subtype name: sarif+json > Required parameters: N/A > Optional parameters: N/A > Encoding considerations: UTF8 only This needs to begin by saying "binary". The note about being UTF-8 only should appear after that. > Security considerations: Since Sarif files are in JSON format, they inherit the security issues of JSON. There should be a note here to that effect. The specific points listed below are very good, however, this needs to start with a general discussion of the security considerations of the format as a whole, which necessarily leads to some discussion of privacy and integrity. Something like: The Sarif provides the means to capture the results of static analysis tools. Such analysis may include information about software vulnerabilities. As such, Sarif file content may be extremely sensitive, requiring external privacy and integrity protection. Even when the analysis results themselves are not sensitive, Satif files may have other security issues: And then move on to your list. > - The use of absolute paths in analysis result location URIs might reveal > sensitive information about the machine on which the scan was performed. > - The use of the hostname component in analysis result location URI might > reveal the network location of the machine on which the scan was performed. Run information can also be present, and it can include details about when analysis runs are performed. An attacker might be able to leverage this to avoid getting caught doing something naughty... Similarly, information about analysis processing failing with an error might be used to know when it is safe to make some kind of change. It might even be leveraged to attack the analysis process itself. > - The use of raw HTML in message strings expressed in Markdown might allow > arbitrary code execution (for example, through javascript: links). > - The use of deeply nested constructs in Markdown message strings might lead > to stack overflow in some Markdown implementations. This seems a little specific. It might be useful to mention that there may be other Markdown issues that could be exploited. > - Certain properties of the SARIF object model might reveal information about > the machine on which a scan was run. (The specification allows such properties > to be omitted or "redacted".) > - Certain properties of the SARIF object model (such as the command line that > invoked the analysis tool) can contain arbitrary commands which might damage a > machine on which they are run. There doesn't seem to be any discussion of artifacts, file references, or web responses here. I suggest something like: Sarif files can contain artifacts, references to external artifacts, file references, and web responses. Such content can be of any type, and may include compressed material, with all its associated issues. Not very well worded, but you get the idea. > Interoperability considerations: N/A > Published specification: > Static Analysis Results Interchange Format (SARIF) Version 2.1.0. Edited by > Michael C. Fanning and Laurence J. Golding. 27 March 2020. OASIS Standard. > https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html . Latest > stage: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html . > Applications that use this media type: > The following list is not exhaustive: > - Static analysis tools > - Static analysis results visualization tools (viewers) > - Bug filing tools > - Defect databases > - Compliance systems > Fragment identifier considerations: N/A > Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): .sarif, .sarif.json > Macintosh file type code(s): N/A > Person & email address to contact for further information: > Michael C. Fanning (mikefan@microsoft.com), Laurence J. Golding ( > v-lgold@microsoft.com), and Chet Ensign (chet.ensign@oasis-open.org) > Intended usage: LIMITED USE I can understand why you'd say LIMITED USE here - only certain very specific tools would ever use this format - but generally speaking when registrations say "LIMITED USE" they mean that the format is intended for general use within it's realm of applicabiity. While this is entirely your call, I think "COMMON" is actually more appropriate. > Restrictions on usage: N/A > Author: > OASIS Static Analysis Results Interchange Format (SARIF) TC ( > https://www.oasis-open.org/committees/sarif/ ) > Change controller: > OASIS Open ( https://www.oasis-open.org/ ) > Provisional registration? (standards tree only): No =====
          Hide
          chet-oasis Chet Ensign added a comment -

          Michael and Larry responded - addressing the edits.

          Show
          chet-oasis Chet Ensign added a comment - Michael and Larry responded - addressing the edits.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda checked to see if we'll have this updated soon. Larry replied: "Yes, I will take care of it. It's written on my whiteboard

          Show
          chet-oasis Chet Ensign added a comment - Amanda checked to see if we'll have this updated soon. Larry replied: "Yes, I will take care of it. It's written on my whiteboard
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda checked on progress. Larry replied and confirmed that we will have the final copy back to her before July 14th deadline.

          Show
          chet-oasis Chet Ensign added a comment - Amanda checked on progress. Larry replied and confirmed that we will have the final copy back to her before July 14th deadline.
          Hide
          chet-oasis Chet Ensign added a comment -

          Larry sent Amanda email that the change is in a pull request. Not sure how this will work for them.


          Hello Amanda,

          I have incorporated the reviewer's feedback. For the reviewer's convenience, I raised a pull request on the copy of the registration in the SARIF Technical Committee's GitHub repository:

          https://github.com/oasis-tcs/sarif-spec/pull/465

          The reviewer made one comment that I didn't understand, which I captured in a comment in the pull request.

          Thank you!

          Show
          chet-oasis Chet Ensign added a comment - Larry sent Amanda email that the change is in a pull request. Not sure how this will work for them. — Hello Amanda, I have incorporated the reviewer's feedback. For the reviewer's convenience, I raised a pull request on the copy of the registration in the SARIF Technical Committee's GitHub repository: https://github.com/oasis-tcs/sarif-spec/pull/465 The reviewer made one comment that I didn't understand, which I captured in a comment in the pull request. Thank you!
          Hide
          chet-oasis Chet Ensign added a comment - - edited

          Michelle Cotton replied:


          Regarding the comment, this is what the expert had intended:

          Run information can also be present, and it can include details about when
          analysis runs are performed. An attacker might be able to leverage this to
          avoid getting caught doing something naughty.

          My point was that timing information tells you when scans are performed, and
          knowing that might help an attacker making unauthorized change avoid
          scans that would detect those changes.

          Larry replied with revised text. He asked if a GitHub pull request was sufficient for their needs but then attached a text copy of the revised form. A copy is attached to this ticket.

          Show
          chet-oasis Chet Ensign added a comment - - edited Michelle Cotton replied: — Regarding the comment, this is what the expert had intended: Run information can also be present, and it can include details about when analysis runs are performed. An attacker might be able to leverage this to avoid getting caught doing something naughty. My point was that timing information tells you when scans are performed, and knowing that might help an attacker making unauthorized change avoid scans that would detect those changes. — Larry replied with revised text. He asked if a GitHub pull request was sufficient for their needs but then attached a text copy of the revised form. A copy is attached to this ticket.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to confirm that they have sent the request on to the reviewer so they're good for now.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to confirm that they have sent the request on to the reviewer so they're good for now.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to tell us they are waiting on feedback from their expert.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to tell us they are waiting on feedback from their expert.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to tell us that they are waiting on feedback from their expert.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to tell us that they are waiting on feedback from their expert.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote that this is still with the expert.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote that this is still with the expert.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote this this is still with the expert.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote this this is still with the expert.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to tell us this is still with the reviewer.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to tell us this is still with the reviewer.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to tell us this is still with the reviewer.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to tell us this is still with the reviewer.
          Hide
          chet-oasis Chet Ensign added a comment -

          Amanda wrote to notify us that the media types have been registered.

          Amanda Baber via RT via icann.org
          Tue, Sep 15, 9:43 PM (12 hours ago)
          to me, michael.fanning, v-lgold

          Hi all,

          We've registered the following media type:

          application/sarif+json

          Please see

          http://www.iana.org/assignments/media-types

          If you need to update the contact information for this registration, please reply to this email or send a message to iana@iana.org.

          Show
          chet-oasis Chet Ensign added a comment - Amanda wrote to notify us that the media types have been registered. — Amanda Baber via RT via icann.org Tue, Sep 15, 9:43 PM (12 hours ago) to me, michael.fanning, v-lgold Hi all, We've registered the following media type: application/sarif+json Please see http://www.iana.org/assignments/media-types If you need to update the contact information for this registration, please reply to this email or send a message to iana@iana.org.
          Hide
          chet-oasis Chet Ensign added a comment -

          Forwarded Amanda's notice to the TC. Since the registration is done, there is no further work to do here. I'm closing the ticket.

          Show
          chet-oasis Chet Ensign added a comment - Forwarded Amanda's notice to the TC. Since the registration is done, there is no further work to do here. I'm closing the ticket.

            People

            • Assignee:
              chet-oasis Chet Ensign
              Reporter:
              robincover Robin Cover (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: