Bug 2117793

Description of problem:

.NET depends on the internet infrastructure to provide certify the signatures on signed .NET objects. Traditionally the ca's which are used to sign objects are also the ca's that support TLS signing. .NET used the object signing oids EKU on the leaf certs to distinguish between actual object signing certs.

Mozilla used to provide certs that had object signing trust, but mozilla moved away from object signing for extensions and dropped support for those attributes. At the time mozilla dropped object signing, we checked with RHEL users, and dropped supplying any object signing certs as part of the distribution (we maintained the infrastructure, so users could create their own object signing certs).

As a result, when .NET came along they used the tls cert store rather than the object signing cert store. This broke when symantec, the major course of .net object signing certs, was dropped as an email/tls cert, which dropped it from mozilla's supplied roots. This happened around March 2021, and issues were immediately noticed in debian when the picked up the new mozilla root certs.

In 2021, we had discussions with Microsoft and the RH .NET team. For ca-certificates to pick up object signing certs, we needed a repeatable source of object signing cert, which only Microsoft could provide (unless we wanted to create our own root ca program, which we don't). Their was some general website that contained object-signing certs from Microsoft and TLS/Email certs from Mozilla. The issue was the site did not provide properly versioned  images, so we couldn't repeat a build from that site, so there is no way that debian and redhat and other distributions could provide predicable and identifiable versions of ca-certificates.

The problem was put on hold for a year because a solution wasn't available by the time we shipped the ca-certificates release.

.NET turned off object signing until the got agreement with Microsoft on using a microsoft provided object signing list which they shipped internally. Longer turn, they would use the extracted certificates in /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem when they were eventually supplied by the ca-certificate package.

In July 2022, Microsoft was still setting up the code-signing cert. One complication was that they needed both code-signing and time-stamping. Currently most certs that can do time-stampling also does code-signing (again leaf certs get the appropriate EKU), so the lists are combined. Microsoft supplied the first cut of the list to us for our release here:

https://gist.github.com/richlander/800fcac88d595cea225649b76a5361f4

How future releases are made are still TBD. Also we need to deal with Time Stamping in the future as well (will target the first cut of that on Fedora).

Code signing in processes as follows: The above list is just a pem list of code signing certs. That list is read and matched with the mozilla list. Any cert that is in both is lists has the code signing added to the mozilla cert. Any cert that has the same subject as the mozilla cert, but is different is dropped for now (p11-kit does not properly handle those certs). All remaining certs are added to the list as with the comment 'Microsoft code signing only'.

Note that the code signing certs includes expired certs. That is because the code signing signature is based on the time the object was signed, not the current time, so expired certs are still valid. This is why timestamping is important (the timestamp for the object needs to be verified as correct by a time stamping authority at signature time to prevent and end user from playing with their clock to back date the signature to make an expired cert still valid).




Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: