Bug 62064 - p11-kit-trust ignores Entrust certificate
Summary: p11-kit-trust ignores Entrust certificate
Alias: None
Product: p11-glue
Classification: Unclassified
Component: p11-kit (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Stef Walter
QA Contact:
Depends on: 62156
  Show dependency treegraph
Reported: 2013-03-09 14:51 UTC by Kai Engert
Modified: 2013-08-12 10:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Ignored Entrust certificate (plain PEM) (1.56 KB, text/plain)
2013-03-09 14:51 UTC, Kai Engert

Description Kai Engert 2013-03-09 14:51:05 UTC
Created attachment 76225 [details]
Ignored Entrust certificate (plain PEM)

I'm attaching a certificate, which is marked positive for all purposes, but which is apparently being ignored by p11-kit-trust.so

It isn't shown in Firefox cert manager.

It isn't contained in the pem-bundle nor in the pem-directory output.
Comment 1 Stef Walter 2013-03-11 09:29:20 UTC
Hmmm. This certificate is not a valid CA. It is a version 3 CA, but has no Basic Constraints extension.

http://tools.ietf.org/html/rfc5280#page-39  Basic Constraints

   The basic constraints extension identifies whether the subject of the
   certificate is a CA and the maximum depth of valid certification
   paths that include this certificate.

   The cA boolean indicates whether the certified public key may be used
   to verify certificate signatures.  If the cA boolean is not asserted,
   then the keyCertSign bit in the key usage extension MUST NOT be
   asserted.  If the basic constraints extension is not present in a
   version 3 certificate, or the extension is present but the cA boolean
   is not asserted, then the certified public key MUST NOT be used to
   verify certificate signatures.


   Conforming CAs MUST include this extension in all CA certificates
   that contain public keys used to validate digital signatures on
   certificates and MUST mark the extension as critical in such


So if we want to override this, we can do so with a stapled certificate extension. Making this depend on bug #62156.

Do we need a short term  solution?
Comment 2 Kai Engert 2013-03-11 15:13:53 UTC
Here is some research around the affected root CA cert.

I've proposed a potential solution upstream, but I'm not sure if it's acceptable for upstream.
Comment 3 Kai Engert 2013-03-11 15:15:03 UTC
(In reply to comment #1)
> So if we want to override this, we can do so with a stapled certificate
> extension. Making this depend on bug #62156.
> Do we need a short term  solution?

I'm afraid we'll probably need one.
But let's wait a few days for upstream reactions, especially from Entrust.
Comment 4 Kai Engert 2013-03-11 15:39:59 UTC
I think we have the following options:

Ship the replacement intermediate as trusted on Fedora.
This would deviate from upstream behaviour, and wouldn't trust any certificates that have been issued prior to Mar 23 15:18:27 2009 GMT.
I think we shouldn't do that.

Find a workaround that allows p11-kit-trust.so to accept the Entrust-1999 cert as a root CA, despite it's lack of the basic constraint extension.

Although you are right, it's against the specs, this is a legacy certificate.

Because upstream Firefox and NSS do currently support it correctly, p11-kit-trust.so can only be accepted as a complete drop-in replacement, if it delivers the equivalent set of trusted roots.

I believe upstream NSS accepts it, because it doesn't attempt to check all attributes of certificates that been explicitly been marked as trusted.

Would it be possible to p11-kit-trust.so to act in the same way?
At least until you have extension stapling implemented?

Hope that Entrust approves the pledge that I proposed ustream.

However, even if they did, we'd still have to worry about a detail.

The question is, would upstream Mozilla mark the intermediate as explicitly trusted, or simply add it without explicit trust?

If upstream added it without explicit trust, then upstream would work correctly. However, our extraction wouldn't work - because our extraction only acts on certificates with explicit trust flags. I believe it ignores certificates with neutral trust.

This means, if we wanted a solution that fixes the issue without any work to the p11-kit system, then it would be required that upstream adds the intermediate with explicit trust.

Comment 5 Kai Engert 2013-03-11 16:24:18 UTC
It seems likely that there will be a solution for this issue soon.

Entrust has already asked that Mozilla replaces the non-BCE root with a completely equivalent BCE-containing root, this work is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=694536

It's likely that this work will be completed before we need to ship Fedora 19. Once that happens, a workaround at the p11-kit level will become unnecessary.
Comment 6 Stef Walter 2013-03-19 18:12:40 UTC
This can now be fixed by adding a stapled certificate extension. Below is one in the .p11-kit persist format:

label: "Add missing BasicConstraints for Entrust root"
id: "%55%e4%81%d1%11%80%be%d8%89%b9%08%a3%31%f9%a1%24%09%16%b9%70"
class: x-certificate-extension
x-critical: true
value: "%30%03%01%01%FF"

For future reference, the 'id' field is a CKA_ID attribute. Since the entrust certificate is loaded directly from PEM data, it has no CKA_ID, p11-kit trust generates one in the recommended manner by using the SHA-1 hash of the subjectPublicKeyInfo DER contents. So we can use this CKA_ID in the stapled certificate extension to associate this with the certificate and add an extension.

The 'value' field is the raw DER contents of a BasicConstraints that contains CA:TRUE.
Comment 7 Stef Walter 2013-08-12 10:39:41 UTC
Updated .p11-kit file for 0.19.0 and later:

label: "Add missing BasicConstraints for Entrust.net 2048"
id: "%55%e4%81%d1%11%80%be%d8%89%b9%08%a3%31%f9%a1%24%09%16%b9%70"
x-public-key-info: "%30%82%01%22%30%0d%06%09%2a%86%48%86%f7%0d%01%01%01%05%00%03%82%01%0f%00%30%82%01%0a%02%82%01%01%00%ad%4d%4b%a9%12%86%b2%ea%a3%20%07%15%16%64%2a%2b%4b%d1%bf%0b%4a%4d%8e%ed%80%76%a5%67%b7%78%40%c0%73%42%c8%68%c0%db%53%2b%dd%5e%b8%76%98%35%93%8b%1a%9d%7c%13%3a%0e%1f%5b%b7%1e%cf%e5%24%14%1e%b1%81%a9%8d%7d%b8%cc%6b%4b%03%f1%02%0c%dc%ab%a5%40%24%00%7f%74%94%a1%9d%08%29%b3%88%0b%f5%87%77%9d%55%cd%e4%c3%7e%d7%6a%64%ab%85%14%86%95%5b%97%32%50%6f%3d%c8%ba%66%0c%e3%fc%bd%b8%49%c1%76%89%49%19%fd%c0%a8%bd%89%a3%67%2f%c6%9f%bc%71%19%60%b8%2d%e9%2c%c9%90%76%66%7b%94%e2%af%78%d6%65%53%5d%3c%d6%9c%b2%cf%29%03%f9%2f%a4%50%b2%d4%48%ce%05%32%55%8a%fd%b2%64%4c%0e%e4%98%07%75%db%7f%df%b9%08%55%60%85%30%29%f9%7b%48%a4%69%86%e3%35%3f%1e%86%5d%7a%7a%15%bd%ef%00%8e%15%22%54%17%00%90%26%93%bc%0e%49%68%91%bf%f8%47%d3%9d%95%42%c1%0e%4d%df%6f%26%cf%c3%18%21%62%66%43%70%d6%d5%c0%07%e1%02%03%01%00%01"
class: x-certificate-extension
value: "%30%0f%06%03%55%1d%13%01%01%ff%04%05%30%03%01%01%ff"

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.