GRCA Incident: BR Compliance and Document Signing Certificates

[Wayne Thayer]

In bug 1523221 [1], GRCA (Government of Taiwan) has responded to a
misissuance report by stating that the certificates in question are not
intended for serverAuth or emailProtection. However, our policy applies to
certificates **capable** of being used for serverAuth or emailProtection,
including those that omit an EKU extension. GRCA acknowledges this fact,
but has stated that these are document signing certificates, and there are
no standardized EKUs for document signing that they could use to constrain
these certificates [2] without creating interoperability problems [3].

GRCA has now filed an incident report [4 and below] in which they have
proposed a timeline for moving away from this practice that has them
issuing unconstrained certificates that do not comply with the BRs until
the end of 2020. Presumably it would be years longer before these
certificates have all expired.

I would appreciate everyone's input on this issue and the proposed solution.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221#c4
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221#c7
[4] https://bugzilla.mozilla.org/attachment.cgi?id=9051175

== Incident Report ==
1. How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
the time and date.
Taiwan Government PKI has been developed for more than 10 years. Government
PKI and various e-Government applications strictly follow RFC 5280 and the
original ITU-T X.509 standard for certificate format and Validation method.
However, the current use of the extended field of EKU by Browsers on Web
PKI is inconsistent with the original definitions in RFC 5280 and ITU-T
X.509 (please refer to
https://mailarchive.ietf.org/arch/msg/pkix/aYpt23Ea4Ey5nB4kR6QfyND4SPk),
and our Government PKI existed before the definition of the so-called Web
PKI and the new usage of EKU invented by various Browsers.
Taiwan Government joined the restriction of EKU in SSL certificates in
2018, but unfortunately each of the Browsers still forces our Government
PKI to add EKUs to Citizen Certificates other than SSL certificates (the
number of these certificates exceeds 4 million), even if these Citizens
Certificates are not considered by Browsers to be SSL/TLS Certificates in
terms of format and technique.
And there is currently no international standard defined General-Purposed
Signing/Encryption EKU OID can be used, and this topic was also discussed
in the 42nd CABForum at F2F meeting on 2017/10/3 - 2017/10/5 (please refer
to
https://cabforum.org/2017/10/04/2017-10-04-minutes-face-face-meeting-42-taipei/#Determine-Applicability-of-Certificates-by-using-standard-CABF-CP-OIDs),
but so far there is no conclusion.
This issue was again raised in Bugzilla on January 27, 2019 (Bug 1523221),
and we responded immediately, but Mozilla still required that all other
non-SSL certificates must add the EKU.

2. A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.
March 3, 2003: GCA was established
2015年??月??日: GCA配合於SSL類憑證加入EKU
January, 2015: GCA added EKU into SSL certificates accordingly.
October 3, 2017: The use of EKUs was discussed at the 42nd CAB Forum at F2F
meeting, but no consensus was reached at the meeting.
January 27, 2019: The issue of non-SSL certificates issued by GCA without
the EKU was raised in Bugzilla (Bug 1523221) and began to respond.
February 19, 2019: Mozilla still believes that the certificate was
mis-issued and requested an incident report.
February 25, 2019: Discussed with the National Development Council of ROC
and decided to join the Mozilla Policy to include EKUs in non-SSL user
certificates.
January 1, 2021: Officially add EKU to non-SSL user certificates

3. Whether your CA has stopped, or has not yet stopped, issuing
certificates with the problem. A statement that you have will be considered
a pledge to the community; a statement that you have not requires an
explanation.
Taiwan Government began to issue user certificates in 2003 and issued
certificates in accordance with RFC 5280 and the original ITU-T X.509
standard. At that time, there was no such requirement to use EKU, and it
still works according to the standard. Therefore, in addition to SSL
certificates, other non-SSL class certificates have not added EKUs to the
user certificates.
In line with the Mozilla Policy, our GPKI authorities have agreed to
include EKUs in all non-SSL user certificates.
However, due to the development of PKI in Taiwan for many years, the number
of users (more than 4 million valid certificates) and the number of
electronic government application systems related to certificates (more
than 2,000 application systems), the influence range of implementation is
very large, and all subordinate CAs and application system’s owners need to
be coordinated, which is costly and requires a long time. Therefore, after
multiple evaluations, it is decided to officially add the EKU to the user
certificate on January 1, 2021.

4. A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem were issued.
As mentioned in the 3rd point, Taiwan Government has not applied EKU to
non-SSL user certificates/credentials. At this point in time, it can only
be confirmed that the last user certificate without EKU will be issued on
December 31st, 2020.

5. The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged to
CT and then list the fingerprints or crt.sh IDs, either in the report or as
an attached spreadsheet, with one list per distinct problem.
Since there are more than 4 million user certificate/credentials without
EKU (also those are not the SSL/TLS certificates), they would not be
uploaded to CT, and it is not possible to provide the list directly due to
the huge amount.

6. Explanation about how and why the mistakes were made or bugs introduced,
and how they avoided detection until now.
As mentioned in the 1st point, Taiwan Government’s early development of PKI
was in accordance with the RFC 5280 and the original ITU-T X.509 standard.
Later on, the BROWSERS has different definition of the use of EKU on Web
PKI rather than what was originally defined in RFC 5280 and ITU-T X. Also
without any current information on how the International standards define
the General-Purposed Signing/Encryption EKU OID, what was mentioned above
causes the problem.

Taiwan Government has applied EKU to the SSL certificates, although the
non-SSL ones are not. However, those Citizens Certificates would not be
mistaken for the SSL/TLS Certificates (in formatting) by the BROWSERS
technically.

7. List of steps your CA is taking to resolve the situation and ensure such
issuance will not be repeated in the future, accompanied with a timeline of
when your CA expects to accomplish these things.
February 25th, 2019: discussed with the GPKI authorities in Taiwan and
decided to apply EKU to non-SSL user certificates followed by Mozilla’s
policy.
May, 2019: will meet with GPKI subordinate CAs for clarification
August, 2019: will host sessions to explain with the authority of the
voucher application systems
September, 2019 ~ December, 2020: will apply system modification to all
voucher application systems
January 1st, 2021: will apply EKU to all non-SSL user certificates
officially

[Matthew Hardeman]

I think answers to the following questions might be helpful:

1. What software / types of software are being utilized which would give
compatibility issues? What is the validation logic of those applications /
systems?

2. If these certificates don't have a purpose known to or respected by the
WebPKI, why must they be issued from a trust hierarchy which delegates
trust within the WebPKI?

3. If there are outside systems that want to see these certificates chain
to existing roots, perhaps a new SubCA could be spun up with an intention,
from the very start, of being OneCRL listed? (In other words, special
agreement from the root programs that this particular subCA is invalid in
the browsers, but remains unrevoked in the Root CA's CRL?) Obviously this
would require buy-in from the root programs as well as the CA, but maybe
it's a compromise that could be worked out?

4. What if they got a little innovative? Is there any chance they could
require that each of these certificates be issued with a subject including
an email address which has been validated to the standards the programs
require? Then set the client auth and email protection EKUs? They could
even provide the email addresses in question temporarily on a domain they
own, if needed. Would that still result in compatibility issues?

5. Other document signing programs exist and have existed for a long
time. It's a bigger thing in Europe, right? What's unique about this
situation that causes this non-compliance but that hasn't resulted in
non-compliance there?

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Matthew Hardeman]

While sending a message that non-compliance could result in policy change
is generally a bad idea, I did notice something about the profile of the
non-compliant certificate which gave me pause:

None of the example certificates which were provided include a SAN
extension at all.

Today, no valid certificates for the WebPKI lack a SAN extension. There
should always been at least one SAN dnsName, SAN ipAddress, or in case of
S/MIME certificates, a SAN rfc822 name.

I know that Chrome has already fully deprecated non-SAN bearing certs.
Have the other browsers?

I'm wondering whether it's possible or reasonable for policy to update such
that certificates that lack any SAN at all would be out of scope?

On Sat, Mar 16, 2019 at 6:42 PM Matthew Hardeman <mhar...@gmail.com>
wrote:

[Dimitris Zacharopoulos]

On 17/3/2019 1:54 π.μ., Matthew Hardeman via dev-security-policy wrote:
> While sending a message that non-compliance could result in policy change
> is generally a bad idea, I did notice something about the profile of the
> non-compliant certificate which gave me pause:
>
> None of the example certificates which were provided include a SAN
> extension at all.
>
> Today, no valid certificates for the WebPKI lack a SAN extension. There
> should always been at least one SAN dnsName, SAN ipAddress, or in case of
> S/MIME certificates, a SAN rfc822 name.
>
> I know that Chrome has already fully deprecated non-SAN bearing certs.
> Have the other browsers?
>
> I'm wondering whether it's possible or reasonable for policy to update such
> that certificates that lack any SAN at all would be out of scope?

This is a very interesting proposal and would narrow the scope of the
policy to exactly the certificate types used by Mozilla products. There
might be some legacy implementations out there that still use the CN
field to validate a FQDN, IP Address and emailAddress to validate an
e-mail address. If there is a policy change to better specify the scope
adding something more than the EKU, IMHO it should include these legacy
cases too. I made an attempt to describe how that would look like in the
policy but the language can definitely be improved. I used some of the
existing language of section 1.1 of the current policy.

For an end-entity certificate Certificate to be in scope of the Mozilla
Policy, it MUST have:

* either an Extended Key Usage (EKU) extension which contains one or
more of these KeyPurposeIds: anyExtendedKeyUsage,  id-kp-serverAuth,
id-kp-emailProtection; or
* no EKU extension

Additionally, the end-entity certificate MUST have:

* a Subject Alternative Names extension of any of the following types:
dNSName, iPAddress, SRVName, rfc822Name; or
* a subjectDN that contains a commonName attribute (OID: 2.5.4.3) that
point to a Domain Name or IP Address; or
* a subjectDN that contains an emailAddress attribute (OID:
1.2.840.113549.1.9.1) that point to an Email Address.

I hope this is useful.


Dimitris.

[Ryan Hurst]

While it may be true that the certificates in question do not contain SANs, unfortunately, the certificates may still be trusted for SSL since they do not have EKUs.

For an example see "The most dangerous code in the world: validating SSL certificates in non-browser software" which is available at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

What you will see that hostname verification is one of the most common areas applications have a problem getting right. Often times they silently skip hostname verification, use libraries provide options to disable host name verifications that are either off by default, or turned off for testing and never enabled in production.

One of the few checks you can count on being right with any level of predictability in my experience is the server EKU check where absence is interpreted as an entitlement.

Ryan Hurst
(writing in a personal capacity)

[Wayne Thayer]

I agree with Ryan on this. From a policy perspective, we should be
encouraging [and eventually requiring] EKU constraints, not making it
easier to exclude them.

[Dimitris Zacharopoulos]

On 25/3/2019 10:48 μ.μ., Wayne Thayer via dev-security-policy wrote:
> I agree with Ryan on this. From a policy perspective, we should be
> encouraging [and eventually requiring] EKU constraints, not making it
> easier to exclude them.

I was merely copying parts of the existing policy related to "Policy
Scope", not requirements for end-entity certificates. According to the
BRs an EKU for SSL/TLS Certificates is required. I did a quick read on
the Mozilla Policy and didn't find a statement to explicitly require an
EKU for end-entity certificates capable of being used for S/MIME, unless
I missed it. Section 5.3 only describes an EKU requirement for
Intermediate Certificates. Perhaps we should update 5.2 to include a
requirement for EKU for end-entity certificates.

Dimitris.

[Matthew Hardeman]

On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> While it may be true that the certificates in question do not contain
> SANs, unfortunately, the certificates may still be trusted for SSL since
> they do not have EKUs.
>
> For an example see "The most dangerous code in the world: validating SSL
> certificates in non-browser software" which is available at
> https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
>
> What you will see that hostname verification is one of the most common
> areas applications have a problem getting right. Often times they silently
> skip hostname verification, use libraries provide options to disable host
> name verifications that are either off by default, or turned off for
> testing and never enabled in production.
>
> One of the few checks you can count on being right with any level of
> predictability in my experience is the server EKU check where absence is
> interpreted as an entitlement.
>

My ultimate intent was to try to formulate a way in which GRCA could
provide certificates for the applications that they're having to support
for their clients today without having to essentially plan to be
non-compliant for a multi-year period.

It sounds like there's one or more relying-party applications that perform
strict validation of EKU if provided, but would appear not to have a single
standard EKU that they want to see (except perhaps the AnyPurpose.)

I'm confused as to why these certificates, which seem to be utilized in
applications outside the usual WebPKI scope, need to be issued in a trust
hierarchy that chains up to a root in the Mozilla store. It would seem
like the easiest path forward would be to have the necessary applications
include a new trust anchor and issue these certificates outside the context
of the broader WebPKI.

In essence, if there are applications in which these GRCA end-entity
certificates are being utilized where the Mozilla trust store is utilized
as a trust anchor set and for which the validation logic is clearly quite
different from the modern WebPKI validation logic and where that validation
logic effectively requires non-compliance with Mozilla root store policy,
is this even a use case that the program and/or community want to support?

[Jakob Bohm]

I wonder (but can't be sure) if the GRCA requirements analysis is simply
incomplete. Specifically, I see no claim they have actually found a
client tool having all these properties at the same time:

1. That tool fails to accept certificates containing more EKUs than that
tool needs (example, the tool rejects certs with exampleRandomEKUoid,
but accepts certs without it). Yet it accepts certs with no EKU
extension. The rejection happens even if the EKU extension is not
marked critical.

2. It is absolutely necessary for the object/document signing EE certs
to work with that tool.

3. The tool cannot be easily fixed/upgraded to remove the problem.

If there is no such problematic tool in the target environment, GRCA
could (like other CAs in the Mozilla root program) make a list of needed
specific EKU oids and include them all in their certificate template.



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]

On Mon, Mar 25, 2019 at 5:30 PM Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> My ultimate intent was to try to formulate a way in which GRCA could
> provide certificates for the applications that they're having to support
> for their clients today without having to essentially plan to be
> non-compliant for a multi-year period.
>

Matthew,

The existing policy allows for technical solutions to achieve this. Do you
think it's unreasonable to expect that a well-operated CA should be
knowledgeable enough about PKI and client behaviours to identify and
implement such existing technical solutions? If you do, do you have a sense
of where the balance is between the community spelling out the technical
solutions for such problems versus the CA being able to manage to do so
themselves?

Considering the critical role that publicly trusted CAs play, it doesn't
seem too unreasonable to expect them to be as knowledgeable as this
community in matters of PKI, if not more knowledgeable.