This issue is now documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1625767
On Tue, Mar 24, 2020 at 12:29 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Investigation of the situation: > > 2009-03-06 > Microsec Ltd. issued the following root certificate: > - Microsec e-Szigno Root CA 2009 > Expiry date: 2038-01-18 > > 2009-03-09 > Microsec Ltd. issued the following subordinate CA certificates: > - Advanced Class 2 e-Szigno CA 2009 > - Advanced Class 3 e-Szigno CA 2009 > - Advanced Pseudonymous e-Szigno CA 2009 > - Qualified Pseudonymous e-Szigno CA 2009 > - Qualified e-Szigno CA 2009 > > Expiry date of each of these certificates: 2038-01-17 > > > 2009-06-16 > Microsec reissued the following root certificate: > - Microsec e-Szigno Root CA 2009 > Expiry date: 2029-12-30 > In the certificate the following fields were changed: validity > notBefore and notAfter dates, and the certificatePolicies extension. > > Microsec reissued the following subordinate CA certificates: > - Advanced Class 2 e-Szigno CA 2009 > - Advanced Class 3 e-Szigno CA 2009 > - Advanced Pseudonymous e-Szigno CA 2009 > - Qualified Pseudonymous e-Szigno CA 2009 > - Qualified e-Szigno CA 2009 > > Expiry date of each of these certificates (aligned with the new > root): 2029-12-29 > In the certificates the following fields were changed: validity > notBefore and notAfter dates, and the certificatePolicies extension. > > > 2009-12-02 > Microsec reissued the following root certificate: > - Microsec e-Szigno Root CA 2009 > Expiry date was unchanged: 2029-12-30 > The certificatePolicies extension was dropped from the > certificate, and the place of the keyUsage extension changed within the > ASN.1 structure. > > Microsec reissued the following subordinate CA certificates: > - Advanced Class 2 e-Szigno CA 2009 > - Advanced Class 3 e-Szigno CA 2009 > - Advanced Pseudonymous e-Szigno CA 2009 > - Qualified Pseudonymous e-Szigno CA 2009 > - Qualified e-Szigno CA 2009 > > In the certificates the validity notBefore date changed to the > issuance date, the certificatePolicies extension changed to anyPolicy, and > the URL pointing to the location of CPS documents changed to a uniform > value for qualified and non-qualified certificates. > > > In summary, all above certificates were reissued by Microsec two > times during 2009. In these two cases each certificate was reissued with an > unchanged public key and unchanged Subject DN as compared to the previous > corresponding certificate, while some other fields were changed. The CA > certificates were published (apart from the website) through the Microsec > e-Szigno signature creation and validation application, and were (may have > been) also published in the trusted certificate stores of other software. > > The CA certificates were primarily intended for electronic > signatures. It is necessary to be able to validate digital signatures > chaining up to these CAs in the long term (50 years). Since electronic > signature (end user) certificates only contain the Subject DN of the issuer > CA, the reissued (doppelganger) subordinate CA certificates with the same > Subject DN and key are equally suitable for certificate chain building. As > a consequence, revocation of some subordinate CA certificates might cause > validation errors (false negatives) in some signature validation > applications, therefore, Microsec maintained all versions of the CA > certificates as valid. > This solution worked without problems in the creation and > validation of signatures, and Microsec has not received any error reports > in relation to this throughout the years. > Microsec has always published and promoted the use of the latest > version of the CA certificates, but could not prevent the use of the > earlier versions. > > > 2016-11 > Having set up the CCADB, Mozilla introduced more and more > stringent checks, and earlier versions of some of the CA certificates were > added to the database. > Upon the notification from Mozilla, Microsec investigated the > situation, and requested to maintain the validity of the affected CA > certificates due to reasons explained above. Mozilla temporarily approved > to keep all CA certificate verions valid. > > > 2019-11 > In relation to the improvement of the CCADB system Mozilla > launched automated tools for audit letter validation (ALV). These controls > require each subordinate CA certificate in CCADB to be included in one of > the audit letters. The automatic checking is based on the SHA-256 > fingerprint of the certificate. > > During the validation of the Microsec audit letters the ALV tool > found 9 discrepancies, which can be categorized in the following types: > > 1. Formatting problem in the audit letter (5 out of 9) > In the audit letters issued near the beginning of 2019 the SHA-256 > fingerprint of some certificates were split in two parts by a page break > inside the table cell, so the ALV tool was unable to parse the SHA-256 > value. The affected certificates were flagged with ALV failures. > Microsec contacted its auditor about this problem. As a result, > the new audit letters issued near the end of 2019 did not have this > problem, the ALV tool could parse all certificate fingerprints, so the ALV > failures disappeared. > > > 2. Subordinate CA certificates without audit letters (4 out of 9) > The earlier versions of the above mentioned doppelganger > subordinate CA certificates were not included in the audit letters (always > the latest certificate fingerpring was included), so these (4 cases) were > flagged as ALV failures. > Microsec contacted Mozilla again in this matter, referring to the > earlier approval. Mozilla answered that the approval granted 3 years before > could not remain valid indefinitely, so considering the recent changes in > the automated checks, it was required that each valid subordinate CA > certificate should be covered in an audit letter. > Microsec had two options: > - revoke the earlier versions of the affected (doppelganger) > subordinate CA certificates, or > - include them in the scope of the audit and have them appear in > the audit letter. > As 10 years have elapsed since the deprecation of those > certificates and Microsec did not want to have them added to the audit > letters, Microsec decided to revoke the certificates in question. > > 2019-11-29 > All earlier versions of the subordinate CA certificates were > revoked. > The revocation caused errors in the systems of some clients, but > all of those problems were successfully solved by changing the software > configuration. > Microsec registered the revocations in the CCADB system, and the > corresponding ALV failures disappeared. > > > 3. Doppelganger root certificate > CCADB contains one of the earlier versions of the "Microsec > e-Szigno Root CA 2009" certificate, which is now deprecated and not used. > Since root certificates cannot be revoked, following a discussion with > Mozilla experts Microsec requested the auditor to include both certificates > of the root CA in the audit letter. > The latest audit attestation contains both root CA certificates, > so the corresponding ALV failures disappeared. > > As a result, the CCADB currently displays no ALV failures. > > 2020-03-17 > In order to clarify the situation, Microsec made an assessment of > all affected certificates. > > As a result of the in-depth investigation, Microsec has determined > that 7 of the subordinate certificates, which have been issued from the > "Microsec e-Szigno Root CA 2009" root and have already been revoked, are > not in the current CCADB registry. > It was also found that the unused version of the "Microsec > e-Szigno Root CA 2009" Root Certificate of 2009-03-06 is not in the CCADB > registry either. > > 202-03-24 > Microsec uploaded the missing subordinate certificates to the > CCADB registry. > > Microsec uploaded also the "Microsec e-Szigno Root CA 2009" Root > Certificate to the CCADB registry as a doppelganger subordinate certificate. > This will result in an ALV failure (reporting lack of > certification) as the root certificate cannot be revoked and it is not > included in the current audit attestation letters. > To resolve this warning, Microsec shall request a new audit report > from the auditor that includes this third root certificate too. > Until this new audit attestation is uploaded, considering the full > transparency provided by the above detailed investigation and submissions, > Microsec requests Mozilla to disregard this temporary ALV failure. > > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
