Specify allowed encryption schemes about security-txt HOT 15 OPEN

We're fully phasing out PGP for GrapheneOS beyond using it to verify upstream releases when there's no alternative, so we'll be using SSH signing and age encryption for security.txt. We currently refer to our legacy PGP key via openpgp4fpr:65EEFE022108E2B708CBFCF7F9E712E59AF5F22A in the security.txt. PGP is overly complex and we prefer to do away with it altogether. The whole keyring, web of trust system and key server system is overly complex, massive unnecessary attack surface and it's needlessly painful to use. It's a failed approach. I say that as someone who used PGP for many years including for email encryption and I used to sign my emails with it by default.

An example of an age public key is age1dcftzgq00ykgwvxl5te6d5clqgx75h2g54c0u8gjc43mcnea7p7q3ma0yx. This could be written as a URI via data:application/x-age-public-key,age1dcftzgq00ykgwvxl5te6d5clqgx75h2g54c0u8gjc43mcnea7p7q3ma0yx if necessary. It would be simpler if there was another way to do it. It would make more sense to simply use Encryption: age1dcftzgq00ykgwvxl5te6d5clqgx75h2g54c0u8gjc43mcnea7p7q3ma0yx. It begins with age1 and therefore there's no ambiguity. Other plain text public key formats could also be supported this way as long as they're short and begin with an unambiguous prefix.

from security-txt.

The encryption field is not limited to OpenPGP, although that is the most common use case. It is a URI so if you register a URI scheme for age keys, then it would automatically be supported.

Alternatively, a new field can be registered in the IANA registry to support this. Being that the RFC is about to be published, this would be deferred until after that happens.

from security-txt.

We're now using the data URI approach via Encryption: data:application/x-age-public-key,age1dcftzgq00ykgwvxl5te6d5clqgx75h2g54c0u8gjc43mcnea7p7q3ma0yx:

https://grapheneos.org/.well-known/security.txt

I think this syntax is overly complex and I'm willing to deviate from this standard to make it simpler. I would greatly prefer to just use Encryption: age1dcftzgq00ykgwvxl5te6d5clqgx75h2g54c0u8gjc43mcnea7p7q3ma0yx and it's not ambiguous due to the age1 prefix. The could simply permit a string starting with age followed by a single digit version number.

It's straightforward enough to define our own standard with PGP encryption / signing removed and age / SSH added as a replacement but it would be nicer if there was a universal standard. There's quite broad consensus among security researchers and cryptographers that PGP is a bad approach. Supporting it as an option is fine as long as it's not specifically encouraged but otherwise I see this standard as a problem itself, as is currently the case.

from security-txt.

If I understand correctly, this is referring to a public SSH key which you want reporters to use when submitting reports with this protocol:
https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig

The problem is that reporters won't know how to do this unless it is defined somewhere. For example, I can't find a stable document that defines the key format you describe other than the following which doesn't match your keys:
https://www.ietf.org/rfc/rfc4716.txt

IMHO the best way to do this would be to find a reference for the key format, and to register a new URI, something like: "ssh-key:"

from security-txt.

Native age keys aren't SSH keys. It does support using SSH keys.

from security-txt.

That just proves my point :) Without knowing that format of age keys, how is a reporter supposed to know how to use them? We can't assume every reporter knows about age or age keys. If there is a definition for age keys, then a URI can be registered for that and it would be something like:

"Encryption: age:xxxxx"

I looked at the age spec below and only see the format for symmetric keys. Am I missing something? See:
https://github.com/C2SP/C2SP/blob/main/age.md

from security-txt.

Age supports two recipient types: https://github.com/C2SP/C2SP/blob/main/age.md#native-recipient-types

According to the RFC the Encryption field must not contain the key itself. So just put a link to the document containing the age key there, with any explanatory comment you like.

from security-txt.

That defeats the purpose of signing security.txt and the RFC is only useful to the extent that it makes sense. The main use of the standard is to provide a standard location for a file documenting security disclosure. The current overly opinionated approach to how the contents should be structured coercing people into using PGP for signing and encryption is a problem. If you don't see it as one, that's fine, you can have your standard and we'll make our own replacing PGP.

from security-txt.

That defeats the purpose of signing security.txt and the RFC is only useful to the extent that it makes sense. The main use of the standard is to provide a standard location for a file documenting security disclosure. The current overly opinionated approach to how the contents should be structured coercing people into using PGP for signing and encryption is a problem. If you don't see it as one, that's fine, you can have your standard and we'll make our own replacing PGP.

Can you clarify what encryption feature you are referring to? About the encryption key used for sending reports ("Encryption" field) or the signing scheme of the security.txt file itself? I am confused because above you mention the usage of "age" keys in the "Encryption" field but in the comment referenced here we are now talking about the whole file signing (which is being discussed in #216).

In either case, registering a provisional URI for age keys shouldn't be that big of a deal which makes them usable in "Encryption" field that reporters would use when submitting reports. As far as the signing of the entire file, it is possible to extend the RFC with SSH signing, although the actual signing protocol for SSH doesn't see to be a stable standard yet (https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig is the best reference I can find).

from security-txt.

If you don't see it as one, that's fine, you can have your standard and we'll make our own replacing PGP.

I see signing the file at all as pointless. Since you are pulling the security.txt, the signature file, and the key over HTTPS (hopefully!), then the security of the signature reduces to trusting the HTTPS connection anyway so you may as well just rely on that.

from security-txt.

Can you clarify what encryption feature you are referring to?

I was responding to @smfx's earlier reply mentioning that the RFC forbids including the encryption public key in the file. Referring to an age encryption key via an HTTPS URL instead of simply including it in the file simply makes things harder to use and loses the benefit of the file being signed. Might as well not sign the file or include support for signing if there isn't going to be a focus on including as much as possible in the signed file. We do see the value in signing the file but only if we include all the relevant information in it and we don't want to use PGP. We currently use SSH signing (Git tags), signify (app repository metadata and OS releases, but we'll likely replace these with SSH) and standard Android package/update/vbmeta signing. We want our last use of PGP (both signing and encryption) to go away since at least from our perspective it's a legacy and very problematic system.

from security-txt.

I think a lot of this argument gets down to the clarification I initially requested. It seems reasonable, in the context of assuming PGP, to ban putting an actual key in the file because the file is meant to be a "key: value" formatted file and having values run over multiple lines would present difficulties. In the context that an Age key is usually no longer than a URI that point doesn't make sense.

The spec doesn't specifically require an https:// URI because if offers fingerprint lookups and OPENPGPKEY DNS lookup options. I have to admit I had used PGP for years and I would have to Google what to do with such a thing - my point being "not everyone knows what to do with an Age key" wouldn't exactly be a new problem.

from security-txt.

I would suggest some options for moving forward:

1. For the "Encryption" key, if a URI is registered for Age keys, then it can probably be used in this field.
2. For the digital signing, an Internet draft defining the signing scheme as it applies to security.txt would be needed which would modify the existing RFC to allow SSH signing. The same draft can also indicate that the key can appear in the "Encryption" field.

Alternatively, a new field can be registered for a detached signature but it kind of defeats the whole purpose of signing being in the same file as the content.

The challenge here would be to bring SSH signing and Age key formats into the standard world. Right now, neither of them are durable standards yet.

from security-txt.

I don't think a detached signature defeats the purpose as long as it's referred to in the file. An attacker could just as easily strip an inline signature as a field to pretend it hadn't been signed.

from security-txt.

If a detached signature is ok, then registering a new field in the registry is probably the best way to do it. There is a remaining question whether it should be a general field or geared specifically towards SSH signatures.

Also,

from security-txt.