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.
TC members agreed in principle to a Media/MIME type of "application/sarif+json"
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 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".
--