OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: SARIF TC's intent to register "application/sarif+json" media type with IANA

Re the Minuted decision
TC members agreed in principle to a Media/MIME type of "application/sarif+json"


And the open ticket

Coordinate with SARIF TC in registering application/sarif+json media type with IANA
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


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


Coordinate with CTI TC in registering stix/taxii +json media types with IANA

IANA input on security considerations for media type registrations


[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"

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

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".



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]