OASIS Static Analysis Results Interchange Format (SARIF) TC

Expand all | Collapse all

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

  • 1.  SARIF TC's intent to register "application/sarif+json" media type with IANA

    Posted 06-22-2018 17:25
    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". -- .


  • 2.  RE: [sarif] SARIF TC's intent to register "application/sarif+json" media type with IANA

    Posted 06-22-2018 18:05
    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.   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Robin Cover Sent: Friday, June 22, 2018 10:25 AM To: OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org> Cc: Robin Cover <robin@oasis-open.org>; David Keaton <dmk@dmk.com>; Luke Cartey <luke@semmle.com>; Stefan Hagen <stefan@hagen.link>; Larry Golding <larrygolding@comcast.net> Subject: [sarif] 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"   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".       -- .