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

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.

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

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

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

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

• 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

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.

Larry sent link to draft registration: https://github.com/oasis-tcs/sarif-spec/blob/master/IanaRegistrations/sarif-media-type.txt

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

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

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

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

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.

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

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

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

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

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

=====

Michael and Larry responded - addressing the edits.

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

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

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!

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.

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

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

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

Amanda wrote that this is still with the expert.

Amanda wrote this this is still with the expert.

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

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

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.

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.