MTG

I thought about a simple approach. Something like extending the LintInterface to CheckApplies(c *x509.Certificate, issuer *x509.Certificate) bool and Execute(c *x509.Certificate, issuer *x509.Certificate) *LintResult where the issuer is optional. For old...

I believe if the issuer is nil this should be a "weak" failure. Either skip in the sense that this lint does not apply since the issuer is missing or...

It is true that the assumption made was that only TLS certificates are involved. If the scope of zlint is beyond this use case then this lint is not correct....

Back from the RSA conference... Yes, I will double check.

A proposal for this one: > * [ ] #379 - Validate that the PSD2 QCStatement conforms to the ASN.1 module > (**Ref**: [ETSI TS 119 495 v1.4.1, GEN-5.1-1, GEN-5.2.3-1,...

We are still willing to contribute to the ETSI and other lints, as well as update/correct the current ones from ETSI. I am not sure if this helps this discussion,...

I think this is on our scope... I will try to incorporate this in the ETSI related lints also in the main project. These pull requests are not forgotten but...

Updated the implementation. Now two distinct lints exist, one for subject:organizationIdentifier and one for the cabfOrganizationIdentifier extension. Testdata have also been updated and are better documented. Would it be possible...

Revisiting these issues. A check on #399 can be set because this is already implemented in lint_ev_organization_id_missing.go. #400 pull request is also updated.

The implementation in the pull request and jzlint was motivated by the following discussions/pull requests: https://github.com/zmap/zlint/issues/467 https://github.com/zmap/zlint/pull/469 Certificate eeServerCertValidOver398.pem (https://github.com/zmap/zlint/blob/master/v3/testdata/eeServerCertValidOver398.pem) from the testdata, as the name suggests, is valid over...