Re: [saag] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC

[S Moonesamy <[e-mail]>]

Hi Yakov,

Thank you for the quick feedback.

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.

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

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

>There is an ongoing issue with some systems supporting CRLF and some
>only LF, which is why we defined in a more fluid way. This is somewhat
>similar to section 3.5 in RFC 7230 (HTTP 1.1):

Ok.

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

>Well, from the various feedback received so far, there are certainly
>strong opinions expressed whether the proposal itself and many of its
>parts provide value at all :)

It can happen. :)

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

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

>The earlier versions of the draft allowed contact information without
>the full URI which is why the current draft calls this out. In the
>ABNF grammar (section 5), URI references RFC 3986. The assumption is
>that this reference also includes the IANA and all relevant RFCs that
>define URIs, since it would be impractical to list all of them out in
>our draft. Perhaps, the use of RFC 2119 keywords in this specific
>section may not be needed, since the MUST for URI syntax would be
>sufficient.

Ok.

Regards,
S. Moonesamy