Qcstatem psd2 national scheme

[mtgag]

Following discussion at https://github.com/zmap/zlint/issues/847.

This one is a PSD2 related lint.

[defacto64]

@mtgag If I am not mistaken, this lint checks that, in case the organizationIdentifier contains a "locally defined identity type reference" (i.e. it starts with two characters followed by ":"), the QcStatement id-qcs-pkixQCSyntax-v2 is present and contains at least one element of type URI. This is fine, as it is in line with ETSI EN 319 412-1 (§5.1.4), however it's not a specific requirement for PSD2 certificates, but for all qualified certificates.

[mtgag]

@mtgag If I am not mistaken, this lint checks that, in case the organizationIdentifier contains a "locally defined identity type reference" (i.e. it starts with two characters followed by ":"), the QcStatement id-qcs-pkixQCSyntax-v2 is present and contains at least one element of type URI. This is fine, as it is in line with ETSI EN 319 412-1 (§5.1.4), however it's not a specific requirement for PSD2 certificates, but for all qualified certificates.

In check applies it also checks that the certificate has the 0.4.0.19495.2 OID in QcStatements:

    _, isPresent := util.IsQcStatemPresent(c, &util.IdEtsiPsd2Statem)
    if !isPresent {
        return false
    }

in order to be triggered only for such certificates. What would be the proper check? IsAnyEtsiQcStatementPresent (cf. lint_qcstatem_etsi_present_qcs_critical.go)?

[defacto64]

@mtgag , sorry for the wait.

What I meant to say is that this check should be carried out regardless of whether the certificate is of PSD2 type or not, as it is a requirement that applies to all types of qualified certificates. At least, this is my understanding of ETSI EN 319 412-2, and I may well be wrong. If I am right, this lint should (ideally, IMO) not care if the certificate being linted contains the PSD2 QcStatement or not, even less parse it, but just verify if it is a qualified certificate (of any type). From this perspective - or perhaps in any case - I think the correct normative reference for this particular lint should be ETSI EN 319 412-1 §5.1.4 and not ETSI TS 119 495 §5.2.1.

Still from this perspective, some of the code and test files attached to this PR are perhaps, with all due respect, a little overabundant, as the check in question could be achieved in a more streamlined way.

I would like to clarify that IMO there is nothing wrong in doing this check on a PSD2 certificate, but only that it would be worth doing it in a more generalized way given that it is for a requirement that applies to a much broader set of certificates that not just the PSD2 ones, so why not try to hit many more birds with one stone? (apologies to the birds)

[mtgag]

@mtgag , sorry for the wait.

What I meant to say is that this check should be carried out regardless of whether the certificate is of PSD2 type or not, as it is a requirement that applies to all types of qualified certificates. At least, this is my understanding of ETSI EN 319 412-2, and I may well be wrong. If I am right, this lint should (ideally, IMO) not care if the certificate being linted contains the PSD2 QcStatement or not, even less parse it, but just verify if it is a qualified certificate (of any type). From this perspective - or perhaps in any case - I think the correct normative reference for this particular lint should be ETSI EN 319 412-1 §5.1.4 and not ETSI TS 119 495 §5.2.1.

Still from this perspective, some of the code and test files attached to this PR are perhaps, with all due respect, a little overabundant, as the check in question could be achieved in a more streamlined way.

I would like to clarify that IMO there is nothing wrong in doing this check on a PSD2 certificate, but only that it would be worth doing it in a more generalized way given that it is for a requirement that applies to a much broader set of certificates that not just the PSD2 ones, so why not try to hit many more birds with one stone? (apologies to the birds)

Thank you for the feedback. I will take a deeper look into the comments, implementation, test data, and so on. Currently, I am quite busy, and the holiday season is about to start, so I will probably get back to it in a few weeks.