Hi Keith, There have been concerns raised around the use of this proposal specifically for abuse reporting. This draft was not intended for that purpose as discussed earlier: https://mailarchive.ietf.org/arch/msg/last-call/YDa3P3SnnXaEPG7Vm8noDUlS38U I did open an issue in our GitHub for tracking: https://github.com/securitytxt/security-txt/issues/178 Because the proposal includes an IANA registry, this is something that can be discussed after the publication of this draft and added via a registry entry if consensus is reached. Thanks On Wed, Dec 18, 2019 at 4:13 PM Twombley, Keith <Keith.Twombley@xxxxxxxxx> wrote: > > To Whom It May Concern, > > > > I propose a slight modification to the standard to allow organizations to specify an abuse contact. The goal is to provide a separate form of contact for cases where the organization is suspected of originating some security incident or abusive activity, rather than being a potential victim. > > > > Insert and renumber: > > > > 3.5.4. Abuse Contact > > > > This directive indicates an address that incident responders should use for > > reporting security incidents or abuse. The value MAY be an email > > address, a phone number and/or a web page with contact information. > > The "Abuse:" directive MAY be present in a security.txt > > file. If this directive indicates a web URL, then it MUST begin with > > "https://"; (as per section 2.7.2 of [RFC7230]). Security email > > addresses SHOULD use the conventions defined in section 4 of > > [RFC2142]. > > > > 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]. When the value of this directive is an > > email address, it is RECOMMENDED that encryption be used (as per > > Section 3.5.4). > > > > If this directive is missing, then incident responders MAY report security > > incidents or abuse according to the “Contact:” directive. > > > > The precedence SHOULD be in listed order. The first field is the > > preferred method of contact. In the example below, the email address > > is the preferred method of contact. > > > > Abuse: mailto:security@xxxxxxxxxxx > > Abuse: tel:+1-201-555-0123 > > Abuse: https://example.com/security-contact.html > > > > Additionally, in section 5, insert in to the ABNF, the appropriate definitions for the new abuse-field token > > > > field = ack-field / > > contact-field / > > abuse-field / > > encryption-field / > > hiring-field / > > policy-field / > > ext-field > > > > abuse-field = "Abuse" fs SP uri > > > > > > Additionally, in section 6, include a stanza for the new “Abuse:” field: > > > > Field Name: Abuse > > Description: contact information to use for reporting security incidents or abuse > > Multiple Appearances: Yes > > Published in: this document > > Status: current > > Change controller: IESG > > > > Keith Twombley > > Senior Security Engineer > > Blue Cross Blue Shield Association > > 225 N Michigan Avenue > > Chicago, IL 60601 > > keith.twombley@xxxxxxxxx > > 312.297.5811 > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
