(In reply to Eusebio Herrera from comment #1)
this is an Electronic Seal certificate (S/MIME), not an SSL certificate. Due to an error, we sent it to CT logs. That's the reason of appearance in crt.sh.
If my knowledge of the definition of "id-kp-clientAuth" in RFC5280, and the BR section 126.96.36.199 (f) is accurate, this is a (client) SSL certificate. And according to MRSP 2.3 (1): "Mozilla thus requires CA operations relating to issuance of all SSL certificates in the scope of this policy to conform to the Baseline Requirements."
As such, I believe that this certificate too is required to conform to the Baseline Requirements.
Additionally, the published CPS mentions in section 188.8.131.52.3 ("CHAMBERS OF COMMERCE hierarchy") a set of oids that it uses in its published certificates; but that does not include the aforementioned oid. Additionally, your CPS section 184.108.40.206.3.2.2 ("Digital Seal Certificate –LCP") explicitly states "It can also be used as a client machine identification element in secure TLS communication protocols", aknowledging that it is indeed an SSL Certificate.
Due to an error, we sent it to CT logs. That's the reason of appearance in crt.sh.
I fail to see how logging to a Certificate Transparency log is 'an error'.
You seem to suggest that certificates that are issued with this profile are 1.) not an exception, but 2.) are not being sent to CT logs, and 3.) you do not think the existence of this certificate is problematic (other than potentially for the issues documented in Bug 1623384).
I think that is a very dangerous suggestion, and especially 1. is problematic due to the lack of documentation and audits that attest to the usage of this policy identifier and the fact that the certificate was issued with a CA that is included in the Mozilla Root Store, and thus considered publicly trusted.
Please re-evaluate your statement.