Closed Bug 1337412 Opened 4 years ago Closed 4 years ago

mozilla::pkix doesn't handle CAs with otherName constraints (import of email certs fails)

Categories

(Core :: Security: PSM, defect)

52 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1257403

People

(Reporter: Franz.Sirl-kernel, Unassigned)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

With current Thunderbird versions (45.x, 52.0b1) it's impossible to import email recipient certificates when one of the CAs has constraints on otherName. One affected CA is https://crt.sh/?id=12729343 from Intel. This makes it impossible to securely communicate with people from Intel using a current Thunderbird. Last working version was 31.8.0.

The basic problem seems to be that CheckPresentedIDConformsToNameConstraintsSubtrees() in mozilla/security/pkix/lib/pkixnames.cpp doesn't handle otherName constraints at all. The comment https://dxr.mozilla.org/comm-central/source/mozilla/security/pkix/lib/pkixnames.cpp#892 suggests to change RFC5280, but this hasn't happened yet and also won't help already existing (and seemingly valid according to current RFC5280) CAs.

Attached is a tentative patch developed during debugging the above issue that fixes an oversight (no VerifyCA handling) during CA verification. Without it, the above Intel CA can be imported, but it will always report "Could not verify this certificate for unknown reasons." when viewed.

To get an affected email recipient certificate, I would have to ask someone from Intel first.



Actual results:

The import of the certificate was rejected. Additionally, with certverifier:5 logging you get a wrong error hint "EE cert is SHA-1", even though the underlying problem was Result::ERROR_CERT_NOT_IN_NAME_SPACE.


Expected results:

The import of the certificate should succeed.
When you attempt to import the root, do you get a dialog saying "This certificate can’t be verified and will not be imported. The certificate issuer might be unknown or untrusted, the certificate might have expired or been revoked, or the certificate might not have been approved."?

Perhaps more generally, what steps are you taking and what errors are you seeing? (As in, when you import an email recipient certificate, is it just the end-entity certificate? Or is it a bundle of certificates that includes the root?, etc.)
Flags: needinfo?(Franz.Sirl-kernel)
step 1: "Import" the Intel4A subCA. This works fine even without patches.
step 2: "View" the Intel4A subCA. Without the verifyca-patch "Could not verify this certificate for unknown reasons." is reported. With the verifyca-patch "This certificate has been verified for the following uses: CA Verifier" is reported.
step 3: "Import" an "Email Recipient" certificate signed by the Intel4A subCA. This step fails and I debugged the fail to the point where it was clear that it's choking on the otherName naming constraint contained in the Intel4A subCA.

In the meantime I made a tentative patch that just ignores otherName naming constraints. The patch seems to work for importing the "Email Recipient" certificate, but I haven't tried anything else yet. I will attach the patch for reference.
Flags: needinfo?(Franz.Sirl-kernel)
Thanks for the clarification. I think the importing issue will be addressed by bug 1257403 (the same reasoning applies to email certificates as CA certificates in this case, so we'll probably end up not verifying either upon import after that bug). I don't think mozilla::pkix will ever support the use of otherName in name constraints, however.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1257403
You need to log in before you can comment on or make changes to this bug.