Thanks Ryan. It's not entirely obvious, but I understand your logic and it makes sense. If anyone disagrees, please speak up. Meanwhile, I've opened a misissuance bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498463
- Wayne On Thu, Oct 11, 2018 at 3:39 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > 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
