@ceri I'm not sure if "untrusted" is a good choice in naming. To me, there were traditionally three levels:

• trusted (things I explicitly trust, e.g., the private VLAN on my home network)
• untrusted (things I don't trust - like the public upstream on my router is "untrusted" traffic - this doesn't mean the traffic is bad though)
• blacklisted (things I know to be bad and therefore explicitly block, like the IP address of a known spammer)

With certs management, I assume that "untrusted" really never existed, as this would basically be all certificates that are not in the trusted folder (you probably would never add untrusted certificates to begin with) and you would only move them to the blacklisted folder, once they were known to be bad - at which point they're not untrusted, but distrusted.

So, I would suggest to call the folder "distrusted", as - in my ears - it expresses the fact that these things are explicitly not trusted anymore (unlike certificates we don't know about at all, which are untrusted by default). It's also the term that mozilla used when they stopped trusting (and started distrusting) symantec tls certificates: https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/

This is of course splitting hairs, as untrust and distrust can by used as synonyms, but in my understanding, untrusted also carries the alternative meaning of being between trust and distrust, while distrust is more explicit.

It also seems like, any change to this should Cc @kevans.

In D30807#695005, @grembo wrote:

@ceri I'm not sure if "untrusted" is a good choice in naming. To me, there were traditionally three levels:

• trusted (things I explicitly trust, e.g., the private VLAN on my home network)
• untrusted (things I don't trust - like the public upstream on my router is "untrusted" traffic - this doesn't mean the traffic is bad though)
• blacklisted (things I know to be bad and therefore explicitly block, like the IP address of a known spammer)

With certs management, I assume that "untrusted" really never existed, as this would basically be all certificates that are not in the trusted folder (you probably would never add untrusted certificates to begin with) and you would only move them to the blacklisted folder, once they were known to be bad - at which point they're not untrusted, but distrusted.

So, I would suggest to call the folder "distrusted", as - in my ears - it expresses the fact that these things are explicitly not trusted anymore (unlike certificates we don't know about at all, which are untrusted by default). It's also the term that mozilla used when they stopped trusting (and started distrusting) symantec tls certificates: https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/

This is of course splitting hairs, as untrust and distrust can by used as synonyms, but in my understanding, untrusted also carries the alternative meaning of being between trust and distrust, while distrust is more explicit.

IMO this verbiage is all too active for what the feature really does. Trusted certs are trusted because we put them into a directory that OpenSSL understands to mean trusted, while these are simply certs that are not default-trusted.

Can we back this out so I can rethink and reapply in a fashion that doesn't make it rough to MFC future cert changes, please? We can change the in-tree directory in stable/ while still installing to the old location.

It also seems like, any change to this should Cc @kevans.

In D30807#695022, @kevans wrote:

IMO this verbiage is all too active for what the feature really does. Trusted certs are trusted because we put them into a directory that OpenSSL understands to mean trusted, while these are simply certs that are not default-trusted.

So basically "blacklisted" was not the correct term to begin with.

In D30807#695026, @grembo wrote:

In D30807#695022, @kevans wrote:

IMO this verbiage is all too active for what the feature really does. Trusted certs are trusted because we put them into a directory that OpenSSL understands to mean trusted, while these are simply certs that are not default-trusted.

So basically "blacklisted" was not the correct term to begin with.

This is my opinion, yes. I'm still searching for more ideal verbiage

In D30807#695219, @kevans wrote:

So basically "blacklisted" was not the correct term to begin with.

This is my opinion, yes. I'm still searching for more ideal verbiage

If I would just start implementing this (without any external limitations I'm not aware of), I would probably do something like creating one directory called all and one called trusted with entries in trusted being symbolic links to certificates in all and check those into git.

caroot
|-- all
|   `-- GTS_Root_R1.pem
`-- trusted
    `-- GTS_Root_R1.pem -> ../all/GTS_Root_R1.pem

There are probably reasons why this isn't feasible though.

I agree with the three state model. Trusted, untrusted, and distrusted are fine. But for non-native English speakers, that nuance between un- and dis- may be too difficult. How about knownbad?

In D30807#695258, @grembo wrote:

In D30807#695219, @kevans wrote:

So basically "blacklisted" was not the correct term to begin with.

This is my opinion, yes. I'm still searching for more ideal verbiage

If I would just start implementing this (without any external limitations I'm not aware of), I would probably do something like creating one directory called all and one called trusted with entries in trusted being symbolic links to certificates in all and check those into git.

caroot
|-- all
|   `-- GTS_Root_R1.pem
`-- trusted
    `-- GTS_Root_R1.pem -> ../all/GTS_Root_R1.pem

There are probably reasons why this isn't feasible though.

In D30807#695522, @gordon wrote:

I agree with the three state model. Trusted, untrusted, and distrusted are fine. But for non-native English speakers, that nuance between un- and dis- may be too difficult. How about knownbad?

'approved', 'allowed', 'rejected': may be clearer.

In D30807#695022, @kevans wrote:

Can we back this out so I can rethink and reapply in a fashion that doesn't make it rough to MFC future cert changes, please? We can change the in-tree directory in stable/ while still installing to the old location.

On the backing out question, I'm not going to make a fuss if that happens and there is a plan to go forward, but I'm also not inclined to do it unless we can commit the new stuff at the same time. Hope that's a fair balance.

In D30807#695734, @ceri wrote:

'approved', 'allowed', 'rejected': may be clearer.

Those aren't really terms that are usually used in the context of certificates though and using them might raise more questions. It really just seems to be "all certificates" and out of those "trusted ones" (like the "manage certificates" dialog in firefox - you can import and then modify the trust level).

In D30807#695747, @grembo wrote:

In D30807#695734, @ceri wrote:

'approved', 'allowed', 'rejected': may be clearer.

Those aren't really terms that are usually used in the context of certificates though and using them might raise more questions. It really just seems to be "all certificates" and out of those "trusted ones" (like the "manage certificates" dialog in firefox - you can import and then modify the trust level).

I like your concept. or maybe,
removed, retired, rejected?
lastly, IMHO DIStrusted /would/ be the better than UNtrusted, if us/english is not your first spoken language / "native tongue".