Bugzilla

Thanks for commenting publicly! [As an aside: For those following this bug, please note I simultaneously sent an e-mail to their problem reporting email, for which under the BRs they could have used to privately provide their analysis of the incident report]

Apologies for the confusion, I used PSD2 as a short-hand, as I was investigating PSD2 certificates, but as you point out, that's not a correct terminology for this profile.

My understanding was that the violations fall into either one of two buckets:
1. CAs asserting qcs-SemanticsId-Legal and including organizationIdentifier. 
1. CAs asserting qcs-SemanticsId-Legal and omitting organizationIdentifier. The only definition for the semantics of asserting qcs-SemanticsId-Legal that I'm aware of are [ETSI EN 319 412-1 V1.1.1 (2016-02)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf) and [ETSI TS 119 412-1 V1.2.1 (2018-05)](https://www.etsi.org/deliver/etsi_ts/119400_119499/11941201/01.02.01_60/ts_11941201v010201p.pdf)

For the first case, I'm not aware of any such certificates being issued by Izenpe. The only such certificate I'm aware of is https://crt.sh/?id=1580893677 , but that is from a CA not trusted by Mozilla, hence no bug filed.

For the second case, this is the substantive issue that I focused on.

My filing of the issue is based on Izenpe's [SSL CPS](http://www.izenpe.eus/contenidos/informacion/doc_especifica/en_def/adjuntos/Izenpe_CP_website%20certificates_v1.5_(02-2019).pdf) referring to the applicable ETSI standards, as well as its [SSL CP](http://www.izenpe.eus/contenidos/informacion/doc_especifica/en_def/adjuntos/Certificates_Profile.pdf). My understanding is that the relevant profile is from Page 40 of that CP, the sede_nivel_medio_ev_eidas profile.

This profile states that it does include organizationIdentifier in a manner compliant with that of [EN 319 412-3 v1.1.1 (2016-02)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf).

I see several issues, as a result:
1. The certificates do not seem to comply with the listed Certificate Profile, in that they omit the organizationIdentifier that is described in the profile as being `3 caracteres tipo-identidad + Country + - + identificador. Por ejemplo, si usaramos el CIF sería algo como: VATES-A01337260`
1. As far as I can tell, the profile listed in ETSI EN 319 412-3 requires the presence of the `organizationIdentifier` in the Subject (c.f. Section 4.2.1) when asserting the qcs-SemanticsId-Legal OID in qualified certificates.

This latter part is more complex, so let me explain my reasoning: While EN 319 412-1 5.4.1 states as follows:
> When the legal person semantics identifier is included, any present organizationIdentifier attribute in the subject field shall contain information using the following structure in the presented order
It can be clearly read that the organizationIdentifier is optional, because the constraint only applies to 'any present' organizationIdentifier. 

However, because this is qualified, the requirements from ETSI EN 319 411-2 are incorporated for QCP-w, which incorporate the profile of ETSI EN 319 412-3. EN 319 412-3 modifies/extends/"monkeypatches" 319 412-2 in Sections 4.1 and 4.2.1 to extend a requirement for the assertion of organizationIdentifier.

The consequence of this is that, in addition to being incongruent with the CP/CPS, Izenpe is asserting within the certificate extension either (or both) of:
  * extensions that "do not apply in the context of the public Internet" (as interpreted as meaning IETF standards, rather than ETSI), and which it can't "otherwise demonstrate the right to assert the data in a public context" (by virtue of being in conflict with the ETSI requirements that define this extensions usage)
  * "semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA", by virtue of asserting QCP-w with qcs-SemanticsId-Legal, but without including the requisite organizationIdentifier required by ETSI EN 319 412-3.


I realize this is a very long description of the problem, and I'd be happy to evaluate other responses. I apologize that I didn't clarify more of the baseline analysis in the report, to allow Izenpe to evaluate these arguments. I look forward to understanding if I've overlooked important and salient details, either in the CP/CPS or within the relevant ETSI EN/TS documents.

Thanks for commenting publicly! [As an aside: For those following this bug, please note I simultaneously sent an e-mail to their problem reporting email, for which under the BRs they could have used to privately provide their analysis of the incident report]

Apologies for the confusion, I used PSD2 as a short-hand, as I was investigating PSD2 certificates, but as you point out, that's not a correct terminology for this profile.

My understanding was that the violations fall into either one of two buckets:
1. CAs asserting qcs-SemanticsId-Legal and including organizationIdentifier. 
1. CAs asserting qcs-SemanticsId-Legal and omitting organizationIdentifier. The only definition for the semantics of asserting qcs-SemanticsId-Legal that I'm aware of are [ETSI EN 319 412-1 V1.1.1 (2016-02)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf) and [ETSI TS 119 412-1 V1.2.1 (2018-05)](https://www.etsi.org/deliver/etsi_ts/119400_119499/11941201/01.02.01_60/ts_11941201v010201p.pdf)

For the first case, I'm not aware of any such certificates being issued by Izenpe. The only such certificate I'm aware of is https://crt.sh/?id=1580893677 , but that is from a CA not trusted by Mozilla, hence no bug filed.

For the second case, this is the substantive issue that I focused on.

My filing of the issue is based on Izenpe's [SSL CPS](http://www.izenpe.eus/contenidos/informacion/doc_especifica/en_def/adjuntos/Izenpe_CP_website%20certificates_v1.5_(02-2019).pdf) referring to the applicable ETSI standards, as well as its [SSL CP](http://www.izenpe.eus/contenidos/informacion/doc_especifica/en_def/adjuntos/Certificates_Profile.pdf). My understanding is that the relevant profile is from Page 40 of that CP, the sede_nivel_medio_ev_eidas profile.

This profile states that it does include organizationIdentifier in a manner compliant with that of [EN 319 412-3 v1.1.1 (2016-02)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf).

I see several issues, as a result:
1. The certificates do not seem to comply with the listed Certificate Profile, in that they omit the organizationIdentifier that is described in the profile as being `3 caracteres tipo-identidad + Country + - + identificador. Por ejemplo, si usaramos el CIF sería algo como: VATES-A01337260`
1. As far as I can tell, the profile listed in ETSI EN 319 412-3 requires the presence of the `organizationIdentifier` in the Subject (c.f. Section 4.2.1) when asserting the qcs-SemanticsId-Legal OID in qualified certificates.

This latter part is more complex, so let me explain my reasoning: While EN 319 412-1 5.4.1 states as follows:
> When the legal person semantics identifier is included, any present organizationIdentifier attribute in the subject field shall contain information using the following structure in the presented order

It can be clearly read that the organizationIdentifier is optional, because the constraint only applies to 'any present' organizationIdentifier. 

However, because this is qualified, the requirements from ETSI EN 319 411-2 are incorporated for QCP-w, which incorporate the profile of ETSI EN 319 412-3. EN 319 412-3 modifies/extends/"monkeypatches" 319 412-2 in Sections 4.1 and 4.2.1 to extend a requirement for the assertion of organizationIdentifier.

The consequence of this is that, in addition to being incongruent with the CP/CPS, Izenpe is asserting within the certificate extension either (or both) of:
  * extensions that "do not apply in the context of the public Internet" (as interpreted as meaning IETF standards, rather than ETSI), and which it can't "otherwise demonstrate the right to assert the data in a public context" (by virtue of being in conflict with the ETSI requirements that define this extensions usage)
  * "semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA", by virtue of asserting QCP-w with qcs-SemanticsId-Legal, but without including the requisite organizationIdentifier required by ETSI EN 319 412-3.


I realize this is a very long description of the problem, and I'd be happy to evaluate other responses. I apologize that I didn't clarify more of the baseline analysis in the report, to allow Izenpe to evaluate these arguments. I look forward to understanding if I've overlooked important and salient details, either in the CP/CPS or within the relevant ETSI EN/TS documents.