Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

[Fotis Loukos]

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.

Regards,
Fotis

--
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com

[Wayne Thayer]

Thank you for this report Fotis.

> 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.

[Ryan Sleevi]

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.

[Wayne Thayer]

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

[Jakob Bohm]

Another interpretation, which would result in this situation being
not a Mozilla/BR violation is this (I am /not/ saying this is a a
better interpretation, just a possible one).

Mozilla and BR policy requires only that:

1. The DER encoding is technically correct as if no ASN.1 module was
available (e.g. length fields correspond to actual encoded object
length).

2. Any field in the base standard (X.509) and all extensions specified
or referenced in the BRs, Mozilla policy or the standards those
reference must comply with the ASN.1 declarations and semantics there
specified.

Under this alternative reading, encoding "Mozilla doesn't care"
extensions according to the wrong semantics or wrong ASN.1 module is
not a Mozilla concern, though it may be a concern for other root
stores, such as EU's hierarchical listing of trusted issuers of
qualified certificates.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

Please provide citations that you believe support such an interpretation.
If you cannot provide such citations, then it seems as if interpretations
are being made up, which is no more productive than me suggesting that a CA
may have interpreted the relevant sections to mean that every third
Thursday, CAs that want to misissue should send me a bottle of whisky.

When discussing interpretations, it's useful to discuss what _you_ believe,
and not play devil's advocate, especially for other people. If you believe
that alternative interpretations exist, you should be expected to bear the
burden of proof that can describe and explain why you believe such an
interpretation is valid. Otherwise, speculating as to possible
interpretations, especially on behalf of other people, especially in the
context of violations, does not actually help productively resolve
confusion or concern - it merely adds to it and devalues the conversation.

So if your view is that it is a possible interpretation, please demonstrate
why that is.

[Ryan Sleevi]

I've reached to the auditor (in this case, TUVIT) to understand why they
failed to detect this major non-conformity.

Now that I'm back in the states, following the CA/Browser Forum F2F, I've
had a chance to look more closely at the set of CAs that have issued. This
is not a full lint check - I've only included certificates I can minimally
parse as correct in these extensions.

In addition to T-Systems, it appears Certinomis, ComSign, and MULTICERT
have similarly taken to misencoding.

In the case of Certinomis, an example certificate is
https://crt.sh/?q=38d025ffe77ac1cd2142764fce4fb5fc619e5da536b3adac6904036f40addf80

Although it includes a qcStatements, it includes an OID of 0.4.0.1.6, which
is not valid for purpose, with the id-etsi-qct-web extension. It appears
that the "1" is most likely a typo for the full id-etsi-qcs, which is that
of 0.4.0.1862.1.6 - that is, they omitted the 1862 arc. They properly
encode the id-etsi-qcs-QcPDS with its QcLocations. However, they do not
assert compliance with the ETSI EN 319 412-5 profile (that is, OID
"0.4.0.1862.1.1" is not asserted), so this is a semantic misencoding but
not clearly a violation of the asserted profile.

In the case of ComSign, an example certificate is
https://crt.sh/?q=2d5a2596f315ba823758b2a0380de1e0e9cc22d6e045abe45e1cd7fb2c5fe01e

This one is a hot mess of improper encoding, probably best captured by
pointing out the misencoding of RFC 3739's SemanticsInformation from
qcStatement-1 (OID "1.3.6.1.5.5.7.11.1") and the inclusion of an unassigned
ETSI OID ("0.4.0.1862.11.1") that appears to be combining these two.
However, Mozilla has already made a decision about ComSign going forward.

In the case of MULTICERT, they're trusted transitively by AC Camerfirma in
https://crt.sh/?id=573264407 , which is valid for SSL in Mozilla, and an
example cert is
https://crt.sh/?q=5bada9c841242c13c035496d5668d4a59cb91bb839e9e625a9c63c0e687269ab

In this certificate, they completely botched the syntax, treating
"0.4.0.1862.1.6.3" as permitting an optional UTF8String message, which
states "Certificate for website authentication as defined in Regulation
(EU) No 910/2014"

MULTICERT is the most interesting of these. AC Camerfirma has claimed in
Salesforce that the audits are the same as the parent - however, this does
not seem to be met by
https://bug1478933.bmoattachments.org/attachment.cgi?id=8995930 , which is
the disclosed audit for the AC Camerfirma roots (by Auren). Auren's audit
is dated July 14, 2018 and covers the period up to April 13, 2018. The
cross-certificates were issued on Jun 29, 2018 (
https://crt.sh/?id=568548659 ) and Jul 3, 2018 (
https://crt.sh/?id=573264407 ), the former being revoked, the latter, not.

I find this questionable and suspicious, because MULTICERT also operates
its own root (within the Microsoft program), yet no audit information has
been provided (by Microsoft or MULTICERT). The closest I've found is
https://bugzilla.mozilla.org/show_bug.cgi?id=1433320 , which was provided
by DigiCert because of https://crt.sh/?caid=1013 . Based on this, I believe
that the most likely result is that AC Camerfirma has potentially mislead
the community about the state of the audits - or that the misissuing
MULTICERT Sub-CA has been audited multiple times (by both Auren and by
APCER, which seems unlikely).

As a result, it appears we have one clear misissuance by a CA in Mozilla's
program - MULTICERT - and a potential issue with the auditor (APCER –
Associação Portuguesa de Certificação) - and two potential issues - AC
Camerfirma for the potential audit disclosure issue, and Certinomis for the
possible misassertion issue (unless it can demonstrate that ETSI authorized
that OID, it would be violating 7.1.2.4 of the BRs)

[mart...@camerfirma.com]

Hello,

"MULTICERT SSL Certification Authority 001" is a cross-certificate’s CN.

https://crt.sh/?id=479956216
Issuer: (CA ID: 5842)
commonName = MULTICERT Root Certification Authority 01
organizationName = MULTICERT - Serviços de Certificação Electrónica S.A.
countryName = PT
Validity
Not Before: Dec 12 16:00:08 2017 GMT
Not After : Jun 12 16:00:08 2030 GMT
Subject: (CA ID: 84368)
commonName = MULTICERT SSL Certification Authority 001
organizationalUnitName = Certification Authority
organizationName = MULTICERT - Serviços de Certificação Electrónica S.A.
countryName = PT

https://crt.sh/?id=573264407
Issuer: (CA ID: 1114)
commonName = Global Chambersign Root - 2008
organizationName = AC Camerfirma S.A.
serialNumber = A82743287
localityName = Madrid (see current address at www.camerfirma.com/address)
countryName = EU
Validity
Not Before: Jul 3 12:01:18 2018 GMT
Not After : May 20 12:01:18 2025 GMT
Subject: (CA ID: 84368)
commonName = MULTICERT SSL Certification Authority 001
organizationalUnitName = Certification Authority
organizationName = MULTICERT - Serviços de Certificação Electrónica S.A.
countryName = PT

The first one is included into this audit attestation letter that MULTICERT sent us (intermediate CA #5) http://docs.camerfirma.com/publico/Ficheros/I1002_v2_EN_Audit_letter_eIDAS_SSL.PDF

We've claimed in Salesforce that the audits are the same as the parent interpreting that it's in the scope of this audit (what is obviously an error).

We’ve checked before issuing the intermedite certificate the attestation letter, auditor’s references and CPS&CP.

https://ec.europa.eu/futurium/en/system/files/ged/list_of_eidas_accredited_cabs-2018-07-27.pdf (this is the last one)

https://pki.multicert.com/docs/EN/MULTICERT_PJ.ECRAIZ_427_en.pdf
https://pki.multicert.com/docs/EN/MULTICERT_PJ.ECRAIZ_426_en.pdf

I'll explicitly claim in Salesforce into the intermedite certificate issued by Camerfirma the information about the audit attestation letter:
"The TSP was audited according to the following audit criteria, considering OVCP and QCP-w: EN 319 401 v2.1.1, EN 319 411-1 v1.1.1, EN 319 411-2 v2.1.1 as well as the CA Browser Forum “Baseline Requirements, version 1.4.2” considering the requirements of the ETSI EN 319 403, V2.2.2 (2015-08) for the Trust Service Provider Conformity Assessment."

Regards,
Juan Angel

[Ryan Sleevi]

Thanks for replying. The issue
https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 was filed regarding
this, so it would be good to follow the incident report.

While hindsight is 20/20, and it's encouraging you acknowledge this as
clearly an error, it would be useful for the community to treat this as an
incident and try to understand what the root causes of these errors. "Human
error" doesn't really help devise appropriate solutions and mitigations.
Exploring factors such as how the disclosures are made, what the disclosure
review process is, how that information is compared is more useful to the
community. It sounds like you did have additional information and had the
audit material ready, so understanding how that ended up failed to be
included in Mozilla is good.

While improvements to CCADB in terms of programattic reading of audit
reports would have caught this discrepency, it may be useful for both AC
Camerfirma - and all CAs - to ensure their disclosures are appropriate
based on the /issued/ certificate, and not just the audit statement. That
is, because of the existence of the cross-certificate, under AC
Camerfirma's hierarchy it was distinct. CCADB tries to make this clear, in
that each certificate only lists a single 'parent' (in this case, this
intermediate would be listed with the parent of Camerfirma's certificate),
but I suspect that if other CAs have made this mistake, or other issues
exist with Camerfirma's disclosure, this would be taken very unkindly by
the community.