On Sun, Dec 29, 2019 at 4:39 AM S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote: > > Hi Yakov, > > Thank you for the quick feedback. > Thank you! I am making changes in Github for now with an expectation of a new draft being published once all feedback has been incorporated. > At 07:58 PM 28-12-2019, Yakov Shafranovich wrote: > >All fields are optional except for the "Contact" directive so at a > >minimum, there is a way to contact the organization even without a > >published policy. > > The issue identified in the draft is the lack of mechanisms (or > methods) for "security researchers" to "locate disclosure policies > and contact information for organizations in order to report security > vulnerabilities. It doesn't make sense to make the publication of > disclosure policies optional as it creates uncertainty. Furthermore, > the "SHOULD consult the organization's policy" recommendation in > Section 6.7 does not carry much weight when such information is, by > default, inaccessible. > Phillip Hallam-Baker pointed a similar issue out related to the title of the draft and the use of the term "policy": https://mailarchive.ietf.org/arch/msg/last-call/DOH5NHcDKeQEVGpWox43w1BHOrE Currently I am thinking of changing the title to: "A Format for Describing Vulnerability Disclosure Practices". With this, contact information would be the bare minimum with an organization's policy a highly recommended thing to include (SHOULD). Because some organizations do not want to disclose their policy publicly, the contact information would be the starting point for a researcher. > >Are you saying we should only allow HTTP 1.1 or 2.0? If so, I would > >argue that HTTP 1.0 must be allowed. > > I was actually asking about the meaning of the requirement as the > ambiguity leaves the door open to questions such as the above-mentioned one. > I would change it to read: "for web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) 1.0 [RFC1945] or higher version," > >Being that it is referencing the URI format, the intent is the host as > >per section 3.2.2 of RFC 3986. That would include both domain names > >and IP addresses. We would need to clarify the language to match. > > Ok. I would change it to read: ""MUST only apply to the domain or IP address in the URI used to retrieve it" > > > > Why does the robustness principle require capital letters? (Section 4)? > > > > > > >I am not sure about this question - can you clarify? > > There is a reference to RFC 793. Section 2.10 of that document > contains a statement about the robustness principle. > Fixed to use lower case > > >All jokes aside, we didn't want the registry to be a free for all via > >"First Come First Served" on the one extreme, and be completely > >restricted ("IESG Approval") on the other extreme. We felt an expert > >review would provide the right amount of oversight so something crazy > >doesn't get shoved into the registry. A good example of this would be > >a proposal of a directive indicating that the researcher doesn't have > >permission to test any of the assets - something we couldn't reach > >consensus on earlier. This would be something that would benefit from > >a review by someone versed in security and standards. > > > >The wider community would be the researchers and organizations using > >this format. > > The above explanation is different from the guidance provided in the > draft for the review of a new field. You have an idea of what you do > not wish to see. I suggest finding the appropriate wording for the criteria. > I am rewording this as: "Designated Experts are expected to check whether a proposed registration or update makes sense in the context of industry accepted vulnerability disclosure processes such as {{ISO.29147.2018}} and {{CERT.CVD}}, and provides value to organizations and researchers using this format." > >The reference is to the following language in RFC 2277: > > > > When human-readable text must be presented in a context where the > > sender has no knowledge of the recipient's language preferences (such > > as login failures or E-mailed warnings, or prior to language > > negotiation), text SHOULD be presented in Default Language. > > > >And: > > > > Messages in Default Language MUST be understandable by an English- > > speaking person, since English is the language which, worldwide, the > > greatest number of people will be able to get adequate help in > > interpreting when working with computers. > > > > Note that negotiating English is NOT the same as Default Language; > > Default Language is an emergency measure in otherwise unmanageable > > situations. > > > >Basically, we wanted to come up with a safe default and that was the > >best reference that seemed to indicate that English may be used in > >this case. > > I am not sure whether the assumption in the last two paragraphs is > still valid. Sometimes, there are strong views about that topic. > Some sort of a sane default would be needed here even if it's not perfect. The interpretation described above seems to be similar to what other drafts are doing. For example, see section 2.7 here: https://tools.ietf.org/html/draft-ietf-secevent-http-push-07 If the SET Transmitter did not send an "Accept-Language" header, or if the SET Recipient does not support any of the languages included in the header, the SET Recipient MUST respond with messages that are understandable by an English-speaking person, as described in Section 4.5 of [RFC2277]. Thanks! -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
