-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Qcstatem psd2 national scheme #861
base: master
Are you sure you want to change the base?
Conversation
@mtgag If I am not mistaken, this lint checks that, in case the |
In check applies it also checks that the certificate has the 0.4.0.19495.2 OID in QcStatements:
in order to be triggered only for such certificates. What would be the proper check? IsAnyEtsiQcStatementPresent (cf. lint_qcstatem_etsi_present_qcs_critical.go)? |
@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? |
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. |
Coming back to this issue. Please excuse the delayed answer. On page 9 of https://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.02.01_60/en_31941202v020201p.pdf "Certificates may include one or more semantics identifiers as specified in ETSI ..... Certificates may include one or more semantics identifiers as specified in ETSI EN 319 412-1 [i.4], clause 5 which define the semantics Therefore, the special format applies only when specific semantics identifiers are present and not to all qualified certificates. I believe, that if it implemented as proposed in the following we would cover all cases where the ETSI specification is explicit and thus avoid any false positives: IF What do you think? If it is OK. I could start rewriting this lint. |
There was no feedback on this ticket since several weeks. Is this issue still relevant for review/inclusion? If not, I believe we could close this PR. |
@defacto64 do you still have a particular opinion on this one? |
Sorry for the delay, unfortunately I can only dedicate a very small fraction of my time to this project. |
@mtgag: could you repost your pseudo-code with some indentation so that the processing flow is better understood? |
Sure:
I left the references out to focus on the pseudo-code, the references to support this are found here #861 (comment) |
Your pseudo code seems ok to me, at least the first two conditions.... not sure about the third. It still does not catch non-PSD2 certificates that include the legal person semantics identifier and which therefore are subject to requirement LEG-5.1.4-05 of ETSI EN 319 412-1. Therefore, if the organizationIdentifier in those certificates starts with "two characters etc.", it would be good to "check that the remainder of the string also fulfills the national scheme syntax" in those certificates as well. Besides, it seems to me (perhaps I am missing some cross reference) that ETSI TS 119 495, although requiring that the organizationIdentifier be encoded according to the syntax defined in clause 5.1.4 (Legal person semantics identifier) of ETSI EN 319 412-1, does not require the the certificate includes such semantics identifier. If I was right, than your third condition would be wrong..... frankly, I am not sure at this time. However, if indeed PSD2 certificates are required to include the Legal person semantics identifier when their organizationIdentifier is encoded according to a national scheme, then they would still be linted by the pseudo code that I am suggesting below. Having said that, I would suggest to change the condition for the third case in order to check compliance to requirement LEG-5.1.4-05 of ETSI EN 319 412-1, which certainly applies to both PSD2 and non-PSD2 certificates, like follows:
How about that? Please note that this are just my own personal remarks, that I am expressing here in a personal capacity, and it is not my intent to oppose to this PR. |
There was a transfer error from the first pseudocode here to the second simplified version: It should be:
The corrected part is exactly your proposal which matches the first pseudo-code. Therefore, I think now everything is on the right track. Let us skip the PSD part and just check the natural and legal person aspects. So the final check is:
Ok? |
Well, if that's the case, then it's fine with me. |
Great. I will start working on this and come back to you for a review if this is fine. |
Following discussion at #847.
This one is a PSD2 related lint.