IANA registration for "Bug-Bounty" field

[maribu]

I would like to propose an extension and file a request for registering the new "Bug-Bounty" key.

Following https://www.rfc-editor.org/rfc/rfc9116.html#section-6.2 these are the details:

1. Name of the field being registered or updated
   • Bug-Bounty
2. Short description of the field
   • States whether a a project/company is participating in a bug bounty program and an URI pointing to the details
3. Whether the field can appear more than once
   • More than once if all occurrences have the format Bug-Bounty: <URI>, at most once if the format is Bug-Bounty: None
4. New or updated status
   • current
5. Change controller
   • I have no clue...
6. The document in which the specification of the field is published
   • https://codeberg.org/maribu/security-txt-bug-bounty contains a draft

I have the following open questions:

1. Would someone be available for some exchange on that extension ahead of filing the request to the IANA?
2. Would it be possible to have a more permanent hosting than a personal git repo for the documentation of the new field?
   • Maybe a folder "extensions" can be added to this repo or something in that direction? (I'm happy to open a PR, if so.)
3. Who would be the the change controller?

[nightwatchcyber]

I would recommend making it simpler:

1. We can discuss it here or one of the IETF's lists (SAAG most likely). Let me know which you prefer.
2. The spec says "The document in which the specification of the field is published (if available)" - in your case I would recommend just defining everything in the description so the doc isn't needed.
3. IETF.

For the proposal itself, I would recommend making it simpler and similar tor the existing "Acknowledgments" field and define it as "link to page with information about the organization's bug bounty program; if a web URI, then it MUST begin with 'https://'.

IMHO the "None" option would make things too complicated

[maribu]

Thanks for the quick response. The None option is actually the use case we have. Open source projects with all unpaid maintainers just don't have the money to do any bug bounty programs.

If scrapers for security.txt could filter out projects without bug bounty programs, we wouldn't get emails asking us if we participate in bug bounty programs.

Rephrasing it a bit more bluntly: If following links and reading web sites would be skills such scrapers have mastered and make active use of, they would have followed the policy link and figured out that no bug bounties are available without sending us emails.

How about the following simplification instead?

Bug-Bounty: "True" / "False"

And the details then are to be extracted from the link in the Policy field?

[cqueern]

If scrapers for security.txt could filter out projects without bug bounty programs, we wouldn't get emails asking us if we participate in bug bounty programs.

I empathize. Sounds like that is what we're trying to solve for here.

At the same time I also wonder if there's a universally agreed upon definition of a bug bounty as opposed to vulnerability disclosure programs, responsible disclosure programs, etc.

[maribu]

In my social circles a bug bounty is understood as a monetary reward for reporting a bug (in accordance to some policy). Wikipedia also seems to agree:

If no financial reward is offered, it is called a vulnerability disclosure program.

To reduce any confusion, we could also just define it for the context of the proposed field with something along the lines of: "Reporting a bug can result in a financial reward, as detailed by web page the policy field points to."

[cqueern]

That makes sense and would help distinguish between programs that don't offer a financial reward and those that offer something other than a financial reward like swag or other recognition.

[nightwatchcyber]

I think the binary approach is better ("True/False") and the field should only appear once in the document. For a definition of a bug bounty program, I would reference section 3.5.5 of [CERT.CVD] which is included as a reference in the RFC and here:
https://www.sei.cmu.edu/documents/1945/2017_003_001_503340.pdf

[maribu]

OK, so the updated application would look like this?

1. Name of the field being registered or updated
   • Bug-Bounty
2. Short description of the field
   • A project or company that may financially reward reporters via a bug bounty program as per section 3.5.5 of [CERT.CVD] can indicate this by adding the line "Bug-Bounty: True". Adding the line "Bug-Bounty: False" indicates that no financial reward via a bug bounty program can be offered.
3. Whether the field can appear more than once
   • At most once
4. New or updated status
   • current
5. Change controller
   • IETF
6. The document in which the specification of the field is published
   • Full specification given in point 2, "Short description of the field".

[nightwatchcyber]

cc: @EdOverflow - can you take a look? Thanks

[maribu]

A friendly reminder :-)

[yakovsh]

You would need to formally request it via IANA:
https://www.iana.org/form/protocol-assignment