Bug 1041335

To add context in the proposed patch. This is very similar to the way Android sets the blacklists as well. As it has the certificates in ROM, it needs to place the revoked/blacklisted certificates separately. So applications are pretty much prepared for such handling (e.g., gnutls already has provision for such blacklists).

dupe of bug 1041328 ?

(In reply to Kai Engert (:kaie) from comment #2)
> dupe of bug 1041328 ?

No there are different cases handled by this bug. A non-CA blacklisted certificate for example is not addressed by 1041328, but is addressed by this bug.

(In reply to Nikos Mavrogiannopoulos from comment #0)
> Created attachment 835854 [details]
> Patch
> 
> Description of problem:
> Adding any server certificate in /etc/pki/ca-trust/source/blacklist/ doesn't
> have any impact on programs that utilize
> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.
> 
> A proposed fix is attached, which adds additional files
> such as /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.blacklist.pem, which
> can be read by these applications. 
> 
> I understand that the goal of update-ca-trust tool is to ultimately use pkcs
> #11 to read the trust info, but in the interim time, there has to be a fix
> for non-pkcs11 applications.

What do you imagine such a fix to be. Is there a standard format openssl java and gnutls are using for non-CA blacklists? If so, we can export to it.

If not, lets *please* not invent some arbitrary PEM format or some such. This is exactly what http://p11-glue.freedesktop.org/trust-module.html is for.

I don't understand what do you mean by invent. The PEM format is already invented and it is used already on android systems for black lists. On Fedora instead we have the custom openssl format for black lists as the only alternative to trust module.

We can of course let programs that are not openssl and don't use the trust module ignore the black lists.

(In reply to Nikos Mavrogiannopoulos from comment #5)
> I don't understand what do you mean by invent. The PEM format is already
> invented and it is used already on android systems for black lists. 

What kind of PEM format?

The PEM "BEGIN CERTIFICATE" stuff doesn't support blacklisting by serial+issuer which is one of the ways that our upstream CA source (ie: Mozilla) blacklists certificates.

> On
> Fedora instead we have the custom openssl format for black lists as the only
> alternative to trust module.

This does not support blacklists per se. It only supports how anchors are trusted and/or rejected. Last I checked, the openssl TRUSTED CERTIFICATE stuff is not consulted for non-anchor lookups. Please correct me if I'm wrong here.

Does openssl have standard a way to feed it blacklist information? openssh does implement blacklists on top of openssl. I think this is done specific to the use case though.

> We can of course let programs that are not openssl and don't use the trust
> module ignore the black lists.

They also currently ignore intermediate certificate trust flags, and a whole lot of other things. We indeed have a fair way to go to get everything up to speed. 

Lets invest that effort in using proper lookups (via PKCS#11) rather than yet another temporary (and likely incapable) blacklist format.

That's exactly what this is about:

http://p11-glue.freedesktop.org/doc/storing-trust-policy/

I was referring to the blacklisting process described in update-ca-trust(8). That describes a process where the full PEM certificates are used to form a blacklist. As it is shown in the patch with that process it is easy to extract the output list.

I know about the pkcs11 trust module and this is planned to be used by gnutls in f21. This bug is however for f20.

What software consumes such an (incomplete) blacklist of PEM certificates? I included --filter=blacklist mainly as a diagnosis thing ... but I guess if it's useful.

On the other hand, I don't think it makes sense to have purpose specific blacklists at all.

I don't know if this method of black lists should be used in F20. However from my understanding of the update-ca-trust documentation that was the obvious way to extract the black list. If it is incomplete, i.e., if there are CRLs or OCSP involved there indeed there is no point to extract that list, but that was not the impression I got from the documentation.

If no CRLs or OCSP are involved, we could have a single PEM blacklist as an interim solution until F21 where we switch to a newer gnutls that uses the p11-kit trust module. We could also ignore the issue and have it as a known bug until F21.

The fix for bug #1136817 provides the necessary API to lookup blacklisted certificates on the fly, in conjuction with this logic:

http://p11-glue.freedesktop.org/sharing-trust-policy.html

Do we still need such an interim solution of a blacklist bundle? If there are valid use cases, I (for one) am not against it. But the use cases need to be quite compelling.

No.