Re the Minuted decision TC members agreed in principle to a Media/MIME type of "application/sarif+json"
https://lists.oasis-open.org/archives/sarif/201805/msg00170.html And the open ticket Coordinate with SARIF TC in registering application/sarif+json media type with IANA
https://issues.oasis-open.org/browse/TCADMIN-3008 4.3.1 SARIF MIME type (Co-Chair Cartey) [19:35] Stefan Hagen: Luke presents the status of discussion on the SARIF MIME type [19:38] Luke Cartey: I propose a motion to 1. Agree to proceed with the process of registering a MIME type. [19:38] Luke Cartey: 2. Agree in principle to a MIME type of "application/sarif+json". [19:38] Stefan Hagen: Seconded [19:39] Stefan Hagen: Larry moves to amend by removing the words in principe [19:39] Stefan Hagen: seconded [19:39] Stefan Hagen: no objections [19:39] Stefan Hagen: back to original motion with words in principal removed from 2. part [19:40] Stefan Hagen: No discussion, no objections, unanimous consent. The motion carries [19:40] Stefan Hagen: **Action** on Luke to contact Robin Cover and to follow up what to do for implementing this [19:40] Stefan Hagen: **Action** on Larry to describe the MIME type in the spec (#182 created issue) Please note the comment I added today about IANA expectations for the Securoty Considerations" section of the proposal, when a Notice is sent in for Community Review
https://issues.oasis-open.org/browse/TCADMIN-3008?focusedCommentId=70257&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-70257 Thanks, all, and very best wishes - Robin Robin Cover commented on TCADMIN-3008: ------------------------------ -------- 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 Note especially the "MUST" statements 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. > Coordinate with SARIF TC in registering application/sarif+json media type with IANA > ------------------------------ ------------------------------ ----------------------- > > Key: TCADMIN-3008 > URL:
https://issues.oasis-open.org/ browse/TCADMIN-3008 > Project: Technical Committee Administration > Issue Type: Registration / Template Request > Components: IANA media type registration > Environment: Principal Contact = Luke Cartey, SARIF TC Co-Chair > Reporter: Robin Cover > Assignee: Robin Cover > Priority: Major > > TC members agreed in principle to a Media/MIME type of "application/sarif+json". -- .