Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 5 Feb 2018 09:24:03 -0500

Also, Google now publishes a security.txt file for their domain here:
https://www.google.com/.well-known/security.txt

There are also some tools for various platforms being developed by
community members here:
https://securitytxt.org/projects

Thanks

On Tue, Jan 2, 2018 at 7:01 PM, Yakov Shafranovich
<[email-masked]> wrote:
> FYI
>
> ---------- Forwarded message ----------
> From:  <[email-masked]>
> Date: Wed, Dec 27, 2017 at 11:38 AM
> Subject: New Version Notification for draft-foudil-securitytxt-02.txt
> To: Edwin Foudil <[email-masked]>, Yakov Shafranovich
> <[email-masked]>
>
>
>
> A new version of I-D, draft-foudil-securitytxt-02.txt
> has been successfully submitted by Edwin Foudil and posted to the
> IETF repository.
>
> Name:           draft-foudil-securitytxt
> Revision:       02
> Title:          A Method for Web Security Policies
> Document date:  2017-12-27
> Group:          Individual Submission
> Pages:          13
> URL:
> https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-foudil-securitytxt/
> Htmlized:       https://tools.ietf.org/html/draft-foudil-securitytxt-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-02
>
> Abstract:
>    When security risks in web services are discovered by independent
>    security researchers who understand the severity of the risk, they
>    often lack the channels to properly disclose them.  As a result,
>    security issues may be left unreported. security.txt defines a
>    standard to help organizations define the process for security
>    researchers to securely disclose security vulnerabilities.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 5 Feb 2018 21:12:25 +0000

➢ Also, Google now publishes a security.txt file for their domain here:
    https://www.google.com/.well-known/security.txt
    
OpenSSL is also doing it, as an experiment.  https://www.openssl.org/.well_known/security.txt

---

From: Randy Bush <[email-masked]>
Date: Tue, 06 Feb 2018 23:46:14 +0900

for fun, and because it seemed trivial, i hacked up a security.txt for
https://rg.net/.well-known/security.txt

the document has issues (he said trying to learn californian).  e.g.

2.5.  Signature:

   In order to ensure the authenticty of the security.txt file one
   SHOULD use the "Signature:" directive, which allows you to link to an
   external signature.  External signature files should be named
   "security.txt.sig" and also be placed under the /.well-known/ path.
   External signature files SHOULD be loaded over HTTPS.

   Here is an example of an external signature file.

   Signature: https://example.com/.well-known/security.txt.sig

that is not "an example of an external signature file" at all.  it is an
example of a Signature: line in a security.txt file.  in fact, there is
no definition of a signature file or what it contains other than this
hint.

   To ensure the authenticity of the security.txt file, organizations
   SHOULD sign the file and include the signature using the "Signature:"
   directive.
   
so i guessed and `gpg --clear-signed` the security.txt file with the pgp
key referenced by the "Encryption:" line, producing security.txt.sig
(although the convention would name it .asc).  but i have no belief that
this ensures the authenticity of anything.

randy

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 6 Feb 2018 16:52:44 -0500

Hi Randy,

That is kind of what prompted my earlier question to the list
regarding DNS here:
https://www.ietf.org/mail-archive/web/saag/current/msg08098.html

For the signature, one proposal bouncing around so far has been to
have the signature inline, the other proposal which is in the draft is
to have a second signature file placed next to the file. As you have
highlighted, in both cases there is no definition of what type of
signature it actually is. I don't have a problem standardizing on PGP
signatures but that would kind of lock the proposal to PGP only and I
was hoping to something more extensible.

The obvious bigger problem is that no matter where the signature is
placed (inline or separately), how do we make sure that the signature
is legit? If an attacker can compromise the webspace, then presumingly
they can compromise the signature as well. One proposed solution has
been to ties the authentication of the signature to the domain where
the "security.txt" file is actually placed, and then rely on the fact
that it is harder to compromise DNS vs. the web. Empirical evidence
suggests that may be true but I am not entirely sure. Another
possibility is to tie it to the domain via a CA-issued certificate,
thus relying on the CA verification. However, with LetsEncrypt and
ACME. the webspace (i.e. "well-known" directory) is used for
verification as well, so that puts us back at square one.

Regarding the encryption header, that is the key meant to be used for
encrypting communication between the reporter and the receiving
entity:

2.4.  Encryption:

   This directive allows you to add your key for encrypted
   communication.  You MUST NOT directly add your key.  The value MUST
   be a link to a page which contains your key.  Keys SHOULD be loaded
   over HTTPS.

Thanks

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Feb 2018 23:47:59 +0000

Hiya,

On 06/02/18 21:52, Yakov Shafranovich wrote:
> is legit? 

I don't have a solution, but one thought is that if I wanted
to report something to the contact point, and if the current
security.txt file has changed since I last looked, perhaps I
ought use both the last-but-one and the current value. (The
current value being at risk of being attacker-controlled.)

So, yes, append-only logs (like CT) may have a role here.

One ickky hack idea might be to map the desired content of
security.txt into certbot/openssl command line options that
end up in the CSR, then shoot that at LE using the HTTP
challenge  type (easy enough since one is assumed to control
.well-known) then log the resulting bastardised cert into
the current CT logs.

You'd also want to figure a way that a potential reporter
could easily spot the right values via crt.sh I suppose.

And all of the above could still use a security.txt file,
you'd just also include the command(s) used as well:-)

Renewal could be tricky given the LE 90 day lifetime. But
one could have a fun argument that expiry is no big deal in
this case. (Send your reporting email to all of 'em.)

The above would of course also require one to hold one's
nose for at least the time it takes to type the command:-)

And of course all of that just adds up to "put an email in
the cert for your domain" and "encourage folks to send issues
to that email."

S.

PS: I like the idea of something like this - the above might
read as if I don't. But I do:-)

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Feb 2018 10:31:12 +0900

> read as if I don't. But I do:-)

same.  but it is not well thought out and not usefully prototyped.

if the signed security.txt.sig contains security.txt, who the heck needs
security.txt?  and emacs is easier to use than the web site; ok, vi for
the younger folk.  i suspect that pretty much anyone who would do this
knows how to use a text editor.

for the moment, have the sha256 of the signed blob in a TXT record and
provide a validating tool; your zone is signed, isn't it.  the web site
could do validation for the lazy instead of being a completely gooeyfied
text editor; just pass it the url.

if you want sig flexibility, put it in the file name,
  security.pgp
  security.smime
whatever

keep it simple

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Feb 2018 10:37:36 +0900

% cat security.txt.sig 

Contact: mailto:[email-masked]
Contact: mailto:[email-masked]
Contact: +1 206 356-8341
Encryption: https://archive.psg.com/pgp-key.txt
Signature: https://rg.net/.well-known/security.txt.sig

% sha256 security.txt.sig 
SHA256 (security.txt.sig) = fa1dce4207c0087d19d949bb600613fff2bcd2933e76749afedcb8e5500e70a9

% dig +short security.txt.sig.rg.net. txt
"fa1dce4207c0087d19d949bb600613fff2bcd2933e76749afedcb8e5500e70a9"

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 6 Feb 2018 20:44:07 -0500

> text editor; just pass it the url.

Here is also an example of specifying a signature with URIs:

Signature: dns:security.txt.sig.rg.net?type=TXT

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Feb 2018 10:46:50 +0900

> Signature: dns:security.txt.sig.rg.net?type=TXT

this is an example of no actual authentication.  we leave why it fails
as an exercise for the student.

randy

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 6 Feb 2018 20:54:29 -0500

> text editor; just pass it the url.

Puts the signature with the content, avoids the separate signature
file and provides DNS validation.

Any preference on where in DNS should the validation be placed?

Thanks

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Feb 2018 02:06:13 +0000

➢ Any preference on where in DNS should the validation be placed?
    
There aren’t many places or ways to put information into DNS.  And then you’ve swapped self-certification for trusting an insecure system, no?

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Feb 2018 11:13:07 +0900

> ➢ Any preference on where in DNS should the validation be placed?

at the node over which the sec info is asserting authority.  see my
simple example.

> There aren’t many places or ways to put information into DNS.  And
> then you’ve swapped self-certification for trusting an insecure
> system, no?

you don't run dnssec?  you're kidding, right?

randy

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Feb 2018 02:19:24 +0000

➢ you don't run dnssec?  you're kidding, right?
    
No comment on DNSSEC.  I don’t run any DNS.  And I think we want this to be more widely used than DNSSEC deployment.  Am I mistaken? :)

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 6 Feb 2018 21:26:21 -0500

> at the node over which the sec info is asserting authority.  see my

I did see the example. My question is really around whether there
specific guidance for subdomains like these in DNS? For example, DMARC
(RFC 7489, section 6.1) usually puts its records as TXT in the
"_dmarc.example.com" subdomains. DKIM (RFC 6376, section 3.6.2.1) uses
"_domainkey.example.com" subdomains for public keys. SPF (RFC 7208,
section 3) on the other hand puts stuff in a TXT record for the apex
domain, and doesn't use subdomains.

I also remember back when I was involved with SPF et al, the use of
TXT records was frowned upon, although that seems to have changed.

Thanks

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Feb 2018 11:52:08 +0900

> No comment on DNSSEC.  I don’t run any DNS.  And I think we want this
> to be more widely used than DNSSEC deployment.  Am I mistaken? :)

you want an authenticated second authority.  dns, blockchain, ct, ...
take your pick.  dns was simplest for my hack.  </snark>

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 6 Feb 2018 22:22:45 -0500

And my other question is regarding the hash itself, is there an easy
way to specify the hash function name because SHA-256 will be
deprecated someday. I couldn't find a standard way to specify an
algorithm and a hash, the closest thing is NI, which seems clunky:
"ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q"

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 7 Feb 2018 10:04:25 +0100

Hi,

The document states (in 1.1 Motivation) that the goal is to make the
document machine-parsable. However, when describing the format for
Contact: lines in 2.3, it allows using email addresses to be included
"without a prefix for ease of use and readability" (it's a SHOULD, not a
MUST).

Ease of use and [human] readability is not real concern is the intention
is to be read by machines. On the other hand, the above flexibility will
lead to the need to use regular expressions (or such) to find and parse
the actual email address if one wants to implement automatic
notifications to such addresses. So I feel that this flexibility is
actually a drawback -- I believe the draft should mandate "proper" syntax.

As an alternative, one could split the contact lines into contact-web,
contact-phone, contact-email, contact-postal, ... IRR style entries instead.

Regards,
Robert

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Feb 2018 09:36:23 +0000

Hiya,

> take your pick.  dns was simplest for my hack.  </snark>

Randy is correct - another party is needed in this case for
the signature to be worth anything.

In addition, you do also want some memory of previous values,
as in the event of this being useful you can't necessarily
believe the current values.

So while a DNSSEC'd RR of some sort could validate the hash,
without passive DNS, you'd not get the history, so you'd be
vulnerable to anyone who can re-write the web site and the
RR - though that's still way better than just the web site
in a lot of cases.

For me, that maybe means CT and the X.509 cert for the domain
is worth a look, so I might actually try a certbot/openssl
CLI hack to see if I can get the contact info into the cert
in a usable manner. (I already did publish [1] but I've not
yet verified the signature myself even, so it's just for fun
so far:-) And in case folks aren't familiar with how that
makes history visible, [2] shows the certs I've had for that
domain.

The downside of looking at CT of course is that it's more
likely an attacker could get a new cert from LE for the domain
if they control the web site than it is that the same attacker
could get a new RR published. So a certbot/openssl approach
probably makes the current value less trustworthy than a DNS
based approach. The historical values are still good though
and the change could in itself be a useful signal.

On the third hand, DNSSEC is still rare (it is setup for jell.ie),
so we'd want to think out the DNS-without-DNSSEC cases too. I
think DNS still offers an additional difficulty for an attacker
in that case, for many web sites, so a DKIM-like approach that
doesn't require DNSSEC could also be considered even if it's
strictly less good than one that has DNSSEC.

Lastly, as another off-the-wall idea, archive.org could be a
third party for this if the URL ends up is crawlable. That's
probably not really dependable enough though.

Cheers,
S.

PS: It might be a few days before I get to play with the
certbot/openssl approach mentioned above.

[1] https://jell.ie/.well-known/security.txt
[2] https://crt.sh/?q=jell.ie

> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Feb 2018 19:29:38 +0900

> in a usable manner.

contact schmontact.  just stash the hash of the signed sec doc.  or are
you trying to subsume the whole enchilada?

> could get a new RR published.

the point is making them pwn both.  but you knew that already.  and with
the dns as half, the para^Hprudent can bloody well sign their zone.

> On the third hand, DNSSEC is still rare

while true, there may be a bias toward the kind of folk who would do a
sec contact hack.

but am not wedded to dns; just the possible semantics thereof.

randy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Feb 2018 10:58:52 +0000

> you trying to subsume the whole enchilada?

If the person using the contact information kept
history then sure, ct wouldn't add much. OTOH, if
ct keeps the history then anyone can go find it,
when it's needed/useful. But the ct-angle is just
speculation for now, 'till I or someone else goes
and tries it out.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Feb 2018 12:04:25 +0000

➢ And my other question is regarding the hash itself, is there an easy
    
The s/mime signature formats include the algorithms, it’s just not in readable text.  We also have pgp format.

Trying to start another one, or get involved in that format war, will hurt the cause.

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Feb 2018 21:17:38 +0900

> Trying to start another one, or get involved in that format war, will

it is not like we need pfs here.  and sha256 is likely to last a month
or two

randy

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 07:31:04 -0500

Hi Robert,

Multiple people expressed that concern and in the upcoming -03 version
this has been changed to a regular URI with "mailto" and "tel" in it:
https://github.com/securitytxt/security-txt/issues/62
https://github.com/securitytxt/security-txt/blob/master/draft-foudil-securitytxt.txt#L218

There is also a related issue currently open about a user asking
whether JSON can be supported as an alternative format:
https://github.com/securitytxt/security-txt/issues/12

Thank you

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 07:35:43 -0500

> and the change could in itself be a useful signal.

This is especially true since the same ".well-known" directory is used
by LetsEncrypt for domain verification via ACME before issuing an SSL
certificate, so an attacker that can modify a "security.txt" file in
that directory can probably pass the ACME check as well.

> probably not really dependable enough though.

A member of our project has also put up a prototype crawler that does
something along these lines here:
https://registry.securitytext.org/

Thanks

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 07:44:03 -0500

> it is not like we need pfs here.  and sha256 is likely to last a month

As stated in the other thread, it seems that webspace gets compromised
more often than DNS, although for the various blockchain / ICO
projects, DNS has been attacked more often. Even without DNSSEC the
DNS solution maybe "good enough".

I like Randy's approach for simplicity and I think it may be "good
enough" for this use case. The one thing I would suggest is perhaps
placing the SHA-256 hash under a standard name for the domain or
subdomain where the security.txt file lives as follows:
"hash._securitytxt.example.com" or even just
"_securitytxt.example.com", and the hash would be in a TXT record.

As far as monitoring is concerned, we do currently have language in
the upcoming -03 version asking organizations to monitor their own
files. Perhaps this can be expanded to encourage wider monitoring of
these files by third parties as well.

Thanks

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Feb 2018 16:34:01 +0100

On Mon, Feb 05, 2018 at 09:12:25PM +0000,
 Salz, Rich <[email-masked]> wrote 

> OpenSSL is also doing it, as an experiment.  https://www.openssl.org/.well_known/security.txt

404 It seems they removed it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Feb 2018 16:36:27 +0100

On Tue, Feb 06, 2018 at 04:52:44PM -0500,
 Yakov Shafranovich <[email-masked]> wrote 
 a message of 74 lines which said:

> rely on the fact that it is harder to compromise DNS vs. the
> web. Empirical evidence suggests that may be true but I am not
> entirely sure.

I suggest we do not try to find out whether DNS is secure than the Web
or the opposite. Instead, we could rely on the fact that it is at
least harder to compromise both DNS and the Web than the DNS alone or
the Web alone. So, putting info in the Web and a way to check it
elsewhere (in the DNS) seems reasonable. We don't want a
military-grade solution, just something that it is not obvious for an
attacker to compromise.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Feb 2018 16:40:45 +0100

On Tue, Feb 06, 2018 at 09:26:21PM -0500,
 Yakov Shafranovich <[email-masked]> wrote 
 a message of 21 lines which said:

> My question is really around whether there specific guidance for
> subdomains like these in DNS?

Yes, RFC 5507 and 6950. They are long documents, so here is a one-line
summary:

If you use TXT records, don't put them in the apex of the domain but
underneath.

So, _securitytxt.example.com but not example.com.

> SPF (RFC 7208, section 3) on the other hand puts stuff in a TXT
> record for the apex domain, and doesn't use subdomains.

Yes, but it was done a long time ago without thinking, and it is hard
to change it afterwards.

> TXT records was frowned upon, although that seems to have changed.

Indeed, the conclusion was that, although SPF was cleaner, TXT won:
RFC 6686.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Feb 2018 16:43:37 +0100

On Tue, Feb 06, 2018 at 10:22:45PM -0500,
 Yakov Shafranovich <[email-masked]> wrote 

> "ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q"

I have no problem with RFC 6920 (NI). The future RFC 8315 (which is in
AUTH48-DONE) uses sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

---

From: Paul Wouters <[email-masked]>
Date: Wed, 7 Feb 2018 11:07:49 -0500

> DNS solution maybe "good enough".

That's a low bar. In practice, it seems people have a pretty good success rate
just finding the company's twitter account and letting them know via social media.

And that seems vastly more secure then an untrusted security.txt file backed by
untrusted DNS.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Feb 2018 11:09:20 -0500

> DNS solution maybe "good enough".

DNS is good enough.
Those that want better can and should deploy DNSSEC.

We don't need to boil the ocean here.

While I like having a PGP signed object there (and I think we should
accomodate it), I doubt it will have any significant web of trust.

Or to put it differently: anyone with a PGP web of trust on their signature
probably will never need to be contacted :-)

    > "_securitytxt.example.com", and the hash would be in a TXT record.

+1.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Feb 2018 11:10:15 -0500

> "without a prefix for ease of use and readability" (it's a SHOULD, not a

If that's a goal, then please make it JSON.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Feb 2018 17:17:25 +0000

Typo, sorry.
	https://www.openssl.org/.well-known/security.txt

dash not underscore.  Oops.

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Feb 2018 03:10:21 +0900

> The one thing I would suggest is perhaps placing the SHA-256 hash
> under a standard name for the domain or subdomain where the
> security.txt file lives as follows: "hash._securitytxt.example.com" or
> even just "_securitytxt.example.com", and the hash would be in a TXT
> record.

you seem not to have read my mesage

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 22:25:52 -0500

> speculation for now, 'till I or someone else goes

If I understand correct, it doesn't have to be CT logs per se, just
any kind of a distributed system that would keep monitoring the
security.txt files and keep state in some fashion. So even a
Internet-wide scanning service like DNS Trails or Shodan, could in
theory be sufficient - the question is whether anyone would be willing
to set those up and run them, just like we do with CT logs today.

A member of our project put together one such service here as a prototype:
https://registry.securitytext.org/

Thanks

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 22:29:39 -0500

> So, _securitytxt.example.com but not example.com.

Thank you! And I assume that underscores are preferred as per RFC 2782?

>> An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature."

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 7 Feb 2018 22:31:17 -0500

On Wed, Feb 7, 2018 at 1:10 PM, Randy Bush <[email-masked]> wrote:
> you seem not to have read my message
>

Hi Randy - I did read it, what was confusing is the lack of
underscores that I have seen in other cases like DKIM, DMARC and SRV
records. It looks like that the use of underscores would be
recommended in this case as well?

Thanks

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Feb 2018 12:36:43 +0900

> recommended in this case as well?

avoiding guilt by association with DKIM, DMARC and SRV

and don't actually care

randy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Feb 2018 08:29:29 +0100

On Wed, Feb 07, 2018 at 10:29:39PM -0500,
 Yakov Shafranovich <[email-masked]> wrote 
 a message of 20 lines which said:

> And I assume that underscores are preferred as per RFC 2782?

Yes, because underscores are not allowed in host names, so there is
less risk of collision.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Feb 2018 14:38:36 +0100

On Wed, Feb 07, 2018 at 10:25:52PM -0500,
 Yakov Shafranovich <[email-masked]> wrote 

> https://registry.securitytext.org/

I tried to add google.com (which, according to the whois server, is
not yet scanned) but I always get a "Too Many Attempts"

% whois -h ipv4.whois.securitytext.org securityheaders.io
% SECURITY TXT REGISTRY server at ipv4.whois.securitytext.org
% for more information on SECURITY TXT REGISTRY, visit https://whois.securitytext.org/
% This query returned 1 object
%

"security.txt" on securityheaders.io:

  Domain:         https://registry.securitytext.org/securityheaders.io
  Archive:        https://registry.securitytext.org/domain/f1a2a1b0-fc6b-11e7-a7c9-bfab60ef78d3
  Archive (API):  https://registry.securitytext.org/api/v1/domain/f1a2a1b0-fc6b-11e7-a7c9-bfab60ef78d3
  Contents:       https://registry.securitytext.org/document/db301850-fc6d-11e7-ae5f-8d05bb40e31a
  Contents (API): https://registry.securitytext.org/api/v1/document/db301850-fc6d-11e7-ae5f-8d05bb40e31a
  Hash (SHA512):  9ed54eefbfefe0bf75f196e05d777fb083d12ff1e247f92168a57b423f1767ed46cc2911a9edb20d48ee75de57049437875...
  Created (UTC):  2018-01-18 16:37:21
  Modified (UTC): (not implemented)
  Polled (UTC):   2018-01-18 16:37:21

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-> Contact: [email-masked]                                                                               ->
-> Contact: https://twitter.com/securityheaders                                                                       ->
-> Encryption: https://scotthelme.co.uk/contact/                                                                      ->
->                                                                                                                    ->
->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->

% whois -h ipv4.whois.securitytext.org google.com
% SECURITY TXT REGISTRY server at ipv4.whois.securitytext.org
% for more information on SECURITY TXT REGISTRY, visit https://whois.securitytext.org/
% This query returned 0 objects
%

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Feb 2018 16:15:40 -0500

Sorting the certificate in the DNS seems like a reasonable step, but it seems like a hash of the security.txt would be enough if the zone is DNSSEC signed.

Russ

P.S. I would rather see the file called security.txt.p7s and the detached CMS signature conventions followed.

> On Feb 6, 2018, at 4:52 PM, Yakov Shafranovich <[email-masked]> wrote:
> 
> Hi Randy,
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 10 Feb 2018 13:55:23 +0900

> P.S. I would rather see the file called security.txt.p7s and the
> detached CMS signature conventions followed.

you seem to assume x.509

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Feb 2018 17:11:12 -0500

>> detached CMS signature conventions followed.

One of the approaches that was offered is to put a certificate in the DNS that can be used to validate the signature on the security.txt file, regardless of where it is stored or how it is fetched.  In that context, yes, I am assuming X.509.

I realize that other approaches have also been discussed, including storing a hash of the security.txt file in the DNS.  This seems like a fine solution if the DNS zone is signed with DNSSEC.  In this solution, there is no need for a certificate of any sort.

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Feb 2018 14:43:42 -0800

makes sense

randy