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

S Moonesamy <sm+ietf@elandsys.com> Sat, 28 December 2019 18:02 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2DA12013C; Sat, 28 Dec 2019 10:02:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.687
X-Spam-Level:
X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9B-05-uFK6C; Sat, 28 Dec 2019 10:02:02 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id AB98F120154; Sat, 28 Dec 2019 10:02:02 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.57.14]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xBSI1gJD014217 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Dec 2019 10:01:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1577556115; x=1577642515; i=@elandsys.com; bh=hfFrYxAiTora/SA+HTCiXwQ2aKmUu2401ExK2WT8OAE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=szk+eBSxzB8wiDFtZ1a//P8gLUWQpHL+qjEjfC9EigjbhAvDeEh+0ll17XwboQ0Hd 9hqJJo1rGmH4Jg0ru5tf0YkaMK88IwzGDczQ1rOsZO6DlIo7PfrKqIJi9uLrUGCX+N Qgz+CHE6qIiKfGrBES62gICTDr/sdEXyfIdBTYO0=
Message-Id: <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 28 Dec 2019 09:58:46 -0800
To: saag@ietf.org, draft-foudil-securitytxt@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <157591314890.2123.12378772921757205119.idtracker@ietfa.ams l.com>
References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/S24yIEhWeGVf6lgyKWK-u56XkDs>
Subject: Re: [saag] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Dec 2019 18:02:03 -0000

At 09:39 AM 09-12-2019, The IESG wrote:
>The IESG has received a request from an individual submitter to consider the
>following document: - 'A Method for Web Security Policies'
>   <draft-foudil-securitytxt-08.txt> as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>last-call@ietf.org mailing lists by 2020-01-06. Exceptionally, comments may

Section 1.1 of the draft states that it is about helping 
organizations to communicate information about their security 
disclosure policies.  Is the field defined in Section 3.5.6 optional?

Section 3 sets a requirement for the file (security.txt) to be 
accessible via HTTP and references RFC 1945.  Does it mean that the 
file must be accessible using HTTP/1/0?

Section 3.1 specifies that the file would only apply to the domain in 
the URI.  The examples given in that section states that the file 
also applies to to IPv4 and IPv6 addresses.

There is a requirement in Section 3.3 for the line separator to be 
either CRLF or LF.  Have the authors considered using only one 
convention for specifying the end of line?

Have the authors considered line limits given that the specification 
defines a machine-parsable format?

Why does the robustness principle require capital letters? (Section 4)?

How will the designated expert determine whether a proposed 
registration (Section 7.2) provides value?  What is the "wider 
Internet community"?

How should "MAY assume that English is the default language to be 
used" be interpreted (Section 3.5.7)?  RFC 2777 states that 
"i-default" is not a specific language.

As an overall comment, there are a lot of requirements and 
recommendations (please see RFC 2119) in the draft.  There is, for 
example, a restatement of a requirement: "The value MUST follow the 
URI syntax described in [RFC3986].  This means that "mailto" and 
"tel" URI schemes MUST be used when specifying email addresses and 
telephone numbers, as defined in [RFC6068] and [RFC3966]".  Does that 
comply with the ABNF defined in Section 5?

Regards,
S. Moonesamy