QCP-N-QSCD 411 1(411 2), 412-2 and 412 5

[breynders-cb]

As previously mentioned in #124, a first PR which extends pkilint with QCP-N-QSCD for 411-1 (with restrictions of 411-2), 412-2 and 412-5.

I did my best in maintaining the existing structure of everything, please let me know where you'd want changes and we'll use this PR to get everything aligned as much as possible.

I've generated certificates as integration tests to validate most (or all) rules that I've added as part of the qcp-n-qscd profile.

Additionally:

• I did not add tests, what's the testing policy? I see there's a lot of integration tests and I'm wondering if you have some tool/project set up that can already easily generate all these certificates in the right (i.e. wrong) format. If not I'll start building something for ourselves to generate some test cases for these types (but will take a bit).
• For etsi the finding_metadata.csv seems to be empty, I tried to document all the sources (and changes) but is it on the roadmap to fill in that csv?

And some further questions inlined ⬇️

[breynders-cb]

I was wondering what the source was for this rule. I couldn't really find it other than the reference in 412-5 QCS 4.2. If so, would it need a different source in the validation finding?

[breynders-cb]

Moved to ready-for-review since the ETSI rules are now considered feature-complete from my end (and I'm going to shift towards implementing the POR rules now), looking forward to the feedback!

[CBonnell]

Thank you this great contribution, @breynders-cb! I'm currently traveling for work this week, but will review this PR fully when I return next week.

As for the test case generation, we use der-ascii to generate test artifacts. It has a bit of learning curve to use, but quite powerful and flexible. The test case file format is the PEM text of the artifact followed by the CSV-formatted output of findings. This makes it relatively simple to write test case generation scripts.

We originally did not flesh out the ETSI finding_metadata.csv file, as the ETSI linter references the citation directly in the finding codes. We can certainly flesh out that file if that would be helpful. We are planning to revamp and improve the documentation for findings as part of #64, but haven't had the cycles yet do to so.

[breynders-cb]

Thank you this great contribution, @breynders-cb! I'm currently traveling for work this week, but will review this PR fully when I return next week.

As for the test case generation, we use der-ascii to generate test artifacts. It has a bit of learning curve to use, but quite powerful and flexible. The test case file format is the PEM text of the artifact followed by the CSV-formatted output of findings. This makes it relatively simple to write test case generation scripts.

We originally did not flesh out the ETSI finding_metadata.csv file, as the ETSI linter references the citation directly in the finding codes. We can certainly flesh out that file if that would be helpful. We are planning to revamp and improve the documentation for findings as part of #64, but haven't had the cycles yet do to so.

Great, thanks! I'll add der-ascii to my list of tools, for now I spruced up some of our test code and generated test certificates through bouncy castle so all new rules should have tests in the PEM+csv format.