OASIS Static Analysis Results Interchange Format (SARIF) TC

This list is pretty comprehensive but also tends a bit towards being scary. I wonder whether we could try to adjust the language to provide more nuance on security concerns being related to the purpose to which the format is put. Make sense?
JSON obviously provides a natural mechanism for persisting a URI. Now consider making this statement:
 
“For this reason, again, JSON should only be used in an environment that provides sufficient security.”
 
A text file can contain a clear text password. Consider this statement:
 
“For this reason, again, text files should only be used in an environment that provides sufficient security.”
 
Does my point make sense? Any format is a mechanism for transmitting information that may be insecure. It is most helpful in your guidance to clearly articulate particular places where someone may reasonably transmit data that leads to
security problems. The data is the issue, not the format. The security approach depends on the data that you are transmitting, not, strictly, the format.

 
Can’t resist this: you can say your password aloud and it may be overheard:
 
“For this reason, again, human speech should only be used in an environment that provides sufficient security.”
 

Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.   However, we do need to mention it. In RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:         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.   (NOTE: How is “SHOULD always” different from “SHALL”?

This is improved, thank you.
 

We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention
using HTTPS, that’s no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard,
may not be worth mentioning. All things considered, maybe we just drop the point. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very
bad idea. Let’s not even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data.
 
If they do, a SARIF consumer that is aware of that content should execute it only if it trusts the producer.
 
 


From: Larry Golding (Comcast) <larrygolding@comcast.net>

Sent: Wednesday, June 27, 2018 10:01 AM
To: Michael Fanning <Michael.Fanning@microsoft.com>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration


 
Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.
 
However, we do need to mention it. In
RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:
 
      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.
 
(NOTE: How is “SHOULD always” different from “SHALL”?

Inline   -- Larry   From: Michael Fanning <Michael.Fanning@microsoft.com> Sent: Wednesday, June 27, 2018 3:25 PM To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org> Subject: RE: [sarif] RE: IANA media type registration   This is improved, thank you.   We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention using HTTPS, that’s no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard, may not be worth mentioning. All things considered, maybe we just drop the point. [Larry] Yes, that was my thought: since there wasn’t a well-accepted way to do this, we may as well not mention it. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very bad idea. Let’s not even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data. [Larry] I think what you’re saying is that you’d like my Item #7 to read something like this:   7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary                 properties in a SARIF file (information that is not explicitly defined in the SARIF format).                 SARIF producers should not use this mechanism to define properties that contain executable code or                 script. Right?     From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 10:01 AM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.   However, we do need to mention it. In RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:         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.   (NOTE: How is “SHOULD always” different from “SHALL”?

Agreed on all this. Just want to restate: this guidance is thorough, extremely clear and suited to purpose. Nice work.

 


From: Larry Golding (Comcast) <larrygolding@comcast.net>

Sent: Wednesday, June 27, 2018 4:50 PM
To: Michael Fanning <Michael.Fanning@microsoft.com>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] RE: IANA media type registration


 
Inline
 
-- Larry
 


From: Michael Fanning < Michael.Fanning@microsoft.com >

Sent: Wednesday, June 27, 2018 3:25 PM
To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >;
'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org >
Subject: RE: [sarif] RE: IANA media type registration


 
This is improved, thank you.
 

We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention using HTTPS, that’s
no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard, may not be worth
mentioning. All things considered, maybe we just drop the point.
[Larry] Yes, that was my thought: since there wasn’t a well-accepted way to do this, we may as well not mention it. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very bad idea. Let’s not
even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data.
[Larry] I think what you’re saying is that you’d like my Item #7 to read something like this:
 
7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary
                properties in a SARIF file (information that is not explicitly defined in the SARIF format).
                SARIF producers should not use this mechanism to define properties that contain executable code or
                script.
Right?
 
 


From: Larry Golding (Comcast) < larrygolding@comcast.net >

Sent: Wednesday, June 27, 2018 10:01 AM
To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >;
'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org >
Subject: RE: [sarif] RE: IANA media type registration


 
Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.
 
However, we do need to mention it. In
RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:
 
      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.
 
(NOTE: How is “SHOULD always” different from “SHALL”?

Thanks Michael. I pushed the changes to IANA media type registration form.txt in our repo.   Everyone else, this is still open for discussion until we send the registration request (or even after, I suppose).   Larry   From: Michael Fanning <Michael.Fanning@microsoft.com> Sent: Thursday, June 28, 2018 9:31 AM To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; 'Luke Cartey' <luke@semmle.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org> Subject: RE: [sarif] RE: IANA media type registration   Agreed on all this. Just want to restate: this guidance is thorough, extremely clear and suited to purpose. Nice work.   From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 4:50 PM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Inline   -- Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Wednesday, June 27, 2018 3:25 PM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   This is improved, thank you.   We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention using HTTPS, that’s no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard, may not be worth mentioning. All things considered, maybe we just drop the point. [Larry] Yes, that was my thought: since there wasn’t a well-accepted way to do this, we may as well not mention it. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very bad idea. Let’s not even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data. [Larry] I think what you’re saying is that you’d like my Item #7 to read something like this:   7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary                 properties in a SARIF file (information that is not explicitly defined in the SARIF format).                 SARIF producers should not use this mechanism to define properties that contain executable code or                 script. Right?     From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 10:01 AM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.   However, we do need to mention it. In RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:         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.   (NOTE: How is “SHOULD always” different from “SHALL”?

Hi Larry,  I am still getting up to speed on this process but I think I am safe in *strongly* recommending that you do not change the submission once it has been made to IANA.  IANA subject matter experts will go over the submission and send it back with comments. (I am outlining the experience here I'm working through with CTI now.) The comments will be in-line. A clean copy of the submission will be appended and I will be asked to copy and paste the changes in response to the comments into that copy of the original and return it.  It is good that you all are giving it this much thought ahead of time. That will help with the review. However, I suspect they won't appreciate having new stuff added or changed as that will mean they have to go back over the whole application again.  So folks should speak up now or forever hold their peace as the saying goes...  /chet On Thu, Jun 28, 2018 at 2:41 PM, Larry Golding (Comcast) < larrygolding@comcast.net > wrote: Thanks Michael. I pushed the changes to IANA media type registration form.txt in our repo.   Everyone else, this is still open for discussion until we send the registration request (or even after, I suppose).   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Thursday, June 28, 2018 9:31 AM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' <stefan@hagen.link>; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Agreed on all this. Just want to restate: this guidance is thorough, extremely clear and suited to purpose. Nice work.   From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 4:50 PM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Inline   -- Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Wednesday, June 27, 2018 3:25 PM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   This is improved, thank you.   We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention using HTTPS, that’s no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard, may not be worth mentioning. All things considered, maybe we just drop the point. [Larry] Yes, that was my thought: since there wasn’t a well-accepted way to do this, we may as well not mention it. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very bad idea. Let’s not even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data. [Larry] I think what you’re saying is that you’d like my Item #7 to read something like this:   7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary                 properties in a SARIF file (information that is not explicitly defined in the SARIF format).                 SARIF producers should not use this mechanism to define properties that contain executable code or                 script. Right?     From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 10:01 AM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.   However, we do need to mention it. In RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:         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.   (NOTE: How is “SHOULD always” different from “SHALL”?

Point taken! Thanks for the correction, Chet.   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Chet Ensign Sent: Thursday, June 28, 2018 1:24 PM To: Larry Golding (Comcast) <larrygolding@comcast.net> Cc: Michael Fanning <Michael.Fanning@microsoft.com>; O'Neil, Yekaterina Tsipenyuk <katrina@microfocus.com>; Luke Cartey <luke@semmle.com>; David Keaton <dmk@dmk.com>; Mr. Stefan Hagen <stefan@hagen.link>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org> Subject: Re: [sarif] RE: IANA media type registration   Hi Larry,    I am still getting up to speed on this process but I think I am safe in *strongly* recommending that you do not change the submission once it has been made to IANA.    IANA subject matter experts will go over the submission and send it back with comments. (I am outlining the experience here I'm working through with CTI now.) The comments will be in-line. A clean copy of the submission will be appended and I will be asked to copy and paste the changes in response to the comments into that copy of the original and return it.    It is good that you all are giving it this much thought ahead of time. That will help with the review. However, I suspect they won't appreciate having new stuff added or changed as that will mean they have to go back over the whole application again.    So folks should speak up now or forever hold their peace as the saying goes...    /chet       On Thu, Jun 28, 2018 at 2:41 PM, Larry Golding (Comcast) < larrygolding@comcast.net > wrote: Thanks Michael. I pushed the changes to IANA media type registration form.txt in our repo.   Everyone else, this is still open for discussion until we send the registration request (or even after, I suppose).   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Thursday, June 28, 2018 9:31 AM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Agreed on all this. Just want to restate: this guidance is thorough, extremely clear and suited to purpose. Nice work.   From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 4:50 PM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Inline   -- Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Wednesday, June 27, 2018 3:25 PM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   This is improved, thank you.   We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention using HTTPS, that’s no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard, may not be worth mentioning. All things considered, maybe we just drop the point. [Larry] Yes, that was my thought: since there wasn’t a well-accepted way to do this, we may as well not mention it. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very bad idea. Let’s not even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data. [Larry] I think what you’re saying is that you’d like my Item #7 to read something like this:   7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary                 properties in a SARIF file (information that is not explicitly defined in the SARIF format).                 SARIF producers should not use this mechanism to define properties that contain executable code or                 script. Right?     From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 10:01 AM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.   However, we do need to mention it. In RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:         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.   (NOTE: How is “SHOULD always” different from “SHALL”?

Not a problem. Like I say, I'm still reading through all the documentation myself.  /chet On Thu, Jun 28, 2018 at 4:25 PM, Larry Golding (Comcast) < larrygolding@comcast.net > wrote: Point taken! Thanks for the correction, Chet.   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Chet Ensign Sent: Thursday, June 28, 2018 1:24 PM To: Larry Golding (Comcast) < larrygolding@comcast.net > Cc: Michael Fanning < Michael.Fanning@microsoft.com >; O'Neil, Yekaterina Tsipenyuk < katrina@microfocus.com >; Luke Cartey < luke@semmle.com >; David Keaton < dmk@dmk.com >; Mr. Stefan Hagen <stefan@hagen.link>; OASIS SARIF TC Discussion List < sarif@lists.oasis-open.org > Subject: Re: [sarif] RE: IANA media type registration   Hi Larry,    I am still getting up to speed on this process but I think I am safe in *strongly* recommending that you do not change the submission once it has been made to IANA.    IANA subject matter experts will go over the submission and send it back with comments. (I am outlining the experience here I'm working through with CTI now.) The comments will be in-line. A clean copy of the submission will be appended and I will be asked to copy and paste the changes in response to the comments into that copy of the original and return it.    It is good that you all are giving it this much thought ahead of time. That will help with the review. However, I suspect they won't appreciate having new stuff added or changed as that will mean they have to go back over the whole application again.    So folks should speak up now or forever hold their peace as the saying goes...    /chet       On Thu, Jun 28, 2018 at 2:41 PM, Larry Golding (Comcast) < larrygolding@comcast.net > wrote: Thanks Michael. I pushed the changes to IANA media type registration form.txt in our repo.   Everyone else, this is still open for discussion until we send the registration request (or even after, I suppose).   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Thursday, June 28, 2018 9:31 AM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Agreed on all this. Just want to restate: this guidance is thorough, extremely clear and suited to purpose. Nice work.   From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 4:50 PM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Inline   -- Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Wednesday, June 27, 2018 3:25 PM To: Larry Golding (Comcast) < larrygolding@comcast.net >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   This is improved, thank you.   We deferred an issue around provide mechanisms within SARIF for signing/encrypting data in preference of external mechanisms. Why wouldn’t we cite this as a useful approach? You mention using HTTPS, that’s no different in mind (i.e., it provides a concrete example of a technology that might protect SARIF that contains sensitive info). On the other hand, if the industry can’t decide on a standard/leading JSON payload encryption/signing standard, may not be worth mentioning. All things considered, maybe we just drop the point. [Larry] Yes, that was my thought: since there wasn’t a well-accepted way to do this, we may as well not mention it. This sentence makes me nervous. I don’t think we should even float the idea that a SARIF consumer would expand some executable content from the log file and execute it. This is a very bad idea. Let’s not even float it is my suggestion. Let’s leave the SHOULD guidance on producers not emitting this data. [Larry] I think what you’re saying is that you’d like my Item #7 to read something like this:   7) SARIF defines an extensibility mechanism that allows SARIF producers to include arbitrary                 properties in a SARIF file (information that is not explicitly defined in the SARIF format).                 SARIF producers should not use this mechanism to define properties that contain executable code or                 script. Right?     From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Wednesday, June 27, 2018 10:01 AM To: Michael Fanning < Michael.Fanning@microsoft.com >; 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; 'Luke Cartey' < luke@semmle.com >; 'David Keaton' < dmk@dmk.com >; 'Mr. Stefan Hagen' < stefan@hagen.link >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: RE: [sarif] RE: IANA media type registration   Point taken. I agree that repeating the “appropriate security” mantra over and over is a bit much.   However, we do need to mention it. In RFC 6838 , “Media Type Specifications and Registration Procedures,” Section 4.6, “Security Considerations,” it says:         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.   (NOTE: How is “SHOULD always” different from “SHALL”?