On Fri, Oct 12, 2018 at 2:32 AM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Thank you for this report Fotis. > > On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Summary > > ------- > > > > A number of Qualified Web Authentication Certificates have been issued > > with incorrect qcStatements encoding. A small survey displays that all > > certificates issued by a specific SubCA are affected by this issue > > (https://crt.sh/?CN=%25&iCAID=1481). The CA has been notified about > > this, but more than a week has passed and it has not yet provided any > > feedback, while it continues to issue such malformed certificates (e.g. > > https://crt.sh/?id=816495298). > > > > Technical details > > ----------------- > > > > According to ETSI EN 319 412-5 (Electronic Signature and Infrastructure > > (ESI); Certificate Profiles; Part 5: QCStatements) section 4.2.3 > > (QCStatement claiming that the certificate is a EU qualified certificate > > of a particular type), the QCStatement QcType with OID > > id-etsi-qcs-QcType (0.4.0.1862.1.6) declares that a certificate has been > > issued for a particular purpose (e-sign, e-seal, qualified web > > authentication certificate). Every certificate containing this > > QCStatement must have a SEQUENCE OF OBJECT IDENTIFIER which declares the > > purpose, e.g. id-etsi-qct-web (0.4.0.1862.1.6.3). > > T-Systems International GmbH has failed to follow this specification, > > and instead issues certificates having id-etsi-qct-web as a QCStatement. > > Such a certificate can be found at https://crt.sh/?asn1=795148644. You > > can compare this with https://crt.sh/?asn1=844599393 which has the > > QcType QCStatement correctly encoded. > > > > Disclosure to CA timeline > > ------------------------- > > > > - 2 October 2018: First notification to the CA, with a detailed > > description of the issue. > > - 2 October 2018: Reply by a CA representative that they will look at it. > > - 8 October 2018: Second notification and request for feedback. > > > > No further communication has taken place. > > > > Impact to WebPKI > > ---------------- > > > > Two issues can be identified. > > > > The first issue is the incorrect encoding of the QCStatement. My > > assessment is that this problem does not affect the WebPKI, since as far > > as I can tell, no browsers decode or utilize the QCStatements extension. > > > > The second issue is the failure of the CA to identify the problem, reply > > in time, possibly revoke the problematic certificates and at least > > momentarily pause the issuance of new certificates until the issue is > > resolved. I consider this a serious issue that displays problematic > > practices within the CA. > > > > I share your concern for the CA's responsiveness, but I'm not seeing > anything that would make this a violation of the BRs or Mozilla's policies. The BRs requires certificates to comply with RFC 5280, and that all extensions meet the requirements of 7.1.2.4 of the BRs. Mozilla Root CA Policy 5.2 prohibits both incorrect extensions and invalid DER encoding. These two entries are distinct in policy, as the “invalid DER” rule unambiguously sets restrictions on the encoding rules being adhered to, while the “incorrect extensions” addresses any semantic violation of the encoding (since both of those cases are possible to encode in DER, but their extension definition says you MUST NOT encode entries like that because they do not conform to the extension’s textual definition. The expectation is that if there is a defined ASN.1 module for the extension being included within a certificate, the CA will observe that encoding (Moz Policy 5.2 - “invalid DER”) and semantics (“incorrect extensions”) as defined by the entity responsible for that OID namespace (BRs 7.1.2.4), and as stated in the CA’s CP/CPS (BRs & Moz Policy). I don’t think 7.1.2.4, or Section 5.2 of Mozilla Policy, can be read as “The only things in certificates that need to be properly encoded are those explicitly defined or referenced in RFC 5280,” as that would prohibit the effective deployment of any new extensions. Given that RFC 5280 was explicitly meant to be extendable by a variety of other documents, and through its use of OIDs, without the explicit consent of or coordination with the IETF, taking the narrow view very rapidly leads to logical inconsistencies. For example, to take the narrow “only explicitly in 5280” view, then any DER encoding errors within the subjectPublicKeyIdentifier are totally permissible - because the relevant algorithms aren’t described by, normatively referenced by, not explicitly update 5280. Instead, RFCs like RFC 3447 stand alone, but are used by these other RFCs. With this narrow view, it would be saying that there is carte blanche to ignore normative requirements in any extensible field. That is, any field with an OID can have whatever value or semantics that the CA wants, without violating policy, unless and until such policy explicitly states “you have to follow this precise rule.” For example, if the CA/Browser Forum defined a new extension for validation purposes, it would have to explicitly state in the BRs not just that they must use/include this extension, but that they have to properly encode it as defined by that extension - otherwise, CAs could “use” it while simultaneously misencoding it. The broad view is supported by RFC5280, in that extensions are given the syntax and text within it. That is, extensions are defined as: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } And Section 4.2 of RFC5280 places restrictions through the text, by stating that the extnValue will be the DER encoding of the relevant ASN.1 value. The qcStatements extension has a defined ASN.1 module set by the authority responsible for that extension namespace. In this case, the CA has clearly violated that syntax, and thus failed to uphold Section 4.2 of RFC5280 by producing invalid DER for the defined semantics of that extension, thus violating 7.1.2.4 of the BRs. In addition to that / independent of that violation, by failing to uphold Section 4.2 of RFC5280, it explicitly violates 5.2 of the Mozilla policy. That is, it was so important a policy requirement that it exists twice - in the BRs and in Mozilla Policy - and is alternatively worded so as to explicitly prohibit any confusion by CAs about the expectations. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
