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

4.2.1.9.  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
   certificates. 

...

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?

Here is some research around the affected root CA cert.
https://bugzilla.mozilla.org/show_bug.cgi?id=849833

I've proposed a potential solution upstream, but I'm not sure if it's acceptable for upstream.

(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.

I think we have the following options:

(1)
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.

(2)
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?


(3)
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.


Correct?

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.

This can now be fixed by adding a stapled certificate extension. Below is one in the .p11-kit persist format:

[p11-kit-object-v1]
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
object-id: 2.5.29.19
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.

Updated .p11-kit file for 0.19.0 and later:

[p11-kit-object-v1]
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
object-id: 2.5.29.19
value: "%30%0f%06%03%55%1d%13%01%01%ff%04%05%30%03%01%01%ff"