Taiwan GRCA Root Renewal Request

[Kathleen Wilson]

This request from Government of Taiwan, Government Root Certification Authority (GRCA), is to include their Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits. This root cert will eventually replace the previous GRCA root certificate that was included via Bugzilla Bug #274106.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1065896

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8708619

* Root Certificate Download URL:
http://grca.nat.gov.tw/repository/Certs/GRCA2.cer

* The primary documents are provided in Chinese. The CP and CPS have been translated into English.

CA Document Repository: http://grca.nat.gov.tw/01-06.html
GCA CPS(intermediate that can issue SSL certs):
http://gca.nat.gov.tw/download/Government_Certification_Authority_Certification_Practice_Statement_V1.8.pdf
GPKI CP: http://grca.nat.gov.tw/download/GPKI_CP_eng_v1.7.pdf
GRCA (Root) CPS: http://grca.nat.gov.tw/download/GRCA_CPS_eng_v1.4.pdf

* CA Hierarchy: Diagram of CA Hierarchy: http://grca.nat.gov.tw/
All subordinate CAs are operated by Taiwan Government organizations.
GCA is responsible for signing certificates for government agencies. This is the only intermediate cert that can issue SSL certs.
XCA is responsible for signing certificates for organizations;
MOICA is responsible for signing certificates for citizens;
MOEACA is responsible for signing certificates for corporations; and
HCA is responsible for signing certificates for health agencies.

* This request is to turn on the Email and Websites trust bits.

** GCA CPS section 3.1.11
(1) IC card certificate
Upon obtaining the certificate IC card, subscriber may propose writing its email address onto the certificate.
Upon filing application online with certificate IC card by subscriber, the GCA will check its digital signature as authentication of subscriber’s identity, and send the email verification letter to the certificate email address.
Subscriber shall use the verification letter content reply system to verify it truly owns and controls the email address.
(2) Non-IC card certificate
If required, subscriber may jointly apply for non-IC card certificate and simultaneously writing email address onto certificate.
Aside from checking certificate application information, the GCA shall also send the email verification letter on writing the email address onto the certificate.
Subscriber shall use the verification letter content reply system to verify it truly owns and controls the email address.

** GCA CPS section 3.1.12
The GCA should follow the General Application procedure as set forth in section 3.1.8 for authenticating the organization is true when subscriber applies for SSL Certificate. Also, the GCA may use following method to check that the host domain name truly exists and belongs to the registered under the applicant.
- Government WHOIS host-government Chinese/English domain name registration systems (hhtps://rs.gsn.gov.tw)
- TWNIC Whois Database (http://whois.twnic.net.tw)

* EV Policy OID: Not Requesting EV treatment

* Test Website: https://gcaweb.nat.gov.tw/GCAEE/GCAPriApply/GCAPriApply.html

* CRL URLs:
http://grca.nat.gov.tw/repository/CRL2/CA.crl
http://gca.nat.gov.tw/repository/GCA4/CRL2/complete.crl
The value of nextUpdate is set to 24 hours later than the issuing time (thisUpdate).
CP section 4.4.9: For Level 2, CRL issued at least every 3 days. For level 3 and level 4, CRL issued at least once a day. For Test Level and Level 1 CRL Issuance Frequency is not specified.

* OCSP URL:
http://gca.nat.gov.tw/cgi-bin/OCSP2/ocsp_server.exe
OCSP responses from this service have a maximum expiration time of two hours

* Audit: Annual audits are performed by KPMG according to the WebTrust criteria.
WebTrust CA: https://cert.webtrust.org/SealFile?seal=2050&file=pdf
WebTrust BR: https://cert.webtrust.org/SealFile?seal=2051&file=pdf

* Potentially Problematic Practices: None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of this request from the Government of Taiwan to include their Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits. At the conclusion of this discussion I will provide a summary of issues noted and action items. If there are outstanding issues, then an additional discussion may be needed as follow-up. If there are no outstanding issues, then I will recommend approval of this request in the bug.

Kathleen

[Peter Bowen]

On Fri, Sep 16, 2016 at 2:00 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>
> * CA Hierarchy: Diagram of CA Hierarchy: http://grca.nat.gov.tw/
> All subordinate CAs are operated by Taiwan Government organizations.
> GCA is responsible for signing certificates for government agencies. This is the only intermediate cert that can issue SSL certs.
> XCA is responsible for signing certificates for organizations;
> MOICA is responsible for signing certificates for citizens;
> MOEACA is responsible for signing certificates for corporations; and
> HCA is responsible for signing certificates for health agencies.
>

> * Audit: Annual audits are performed by KPMG according to the WebTrust criteria.
> WebTrust CA: https://cert.webtrust.org/SealFile?seal=2050&file=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2051&file=pdf

I'm having trouble matching up the audits with the subordinate CAs.
There are two different CAs with the same Distinguished Name but
different SubjectPublicKeyInfo and KeyIDs (https://crt.sh/?caid=186
and https://crt.sh/?caid=1330) which makes it trickier than normal,
but either way I'm not seeing all of these subordinates covered in the
audit reports. Can someone please provide a link to each audit report
for each subordinate?

Thanks,
Peter

[hor...@gmail.com]

Kathleen Wilson於 2016年9月17日星期六 UTC+8上午5時00分39秒寫道：

^^^^^the correct URL is https://rs.gsn.gov.tw

[hor...@gmail.com]

Peter Bowen於 2016年9月20日星期二 UTC+8下午11時53分29秒寫道：

GRCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2016.pdf)

GCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2016.pdf)
GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2015.pdf)

XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Report_2016.pdf)

HCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2015.pdf)

MOEACA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2015.pdf)

MOICA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2015.pdf)


National Development Council (TW)

[Kathleen Wilson]

All,

I will greatly appreciate it if you will review this request from Government of Taiwan, Government Root Certification Authority (GRCA) to include their Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits. This root cert will eventually replace the previous GRCA root certificate that was included via Bugzilla Bug #274106.

Thanks,
Kathleen

[lcchen...@gmail.com]

Kathleen Wilson於 2016年11月15日星期二 UTC+8上午9時20分09秒寫道：

In CA/Browser Forum 34th F2F meeting, the minutes is in https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/. Li-Chun Chen (me) of Chunghwa Telecom presented a discussion about "behaviors of web servers and browsers if a PKI follows RFC 4210 & RFC 5280 6.1 for Root CA key Update". The presentation file is in https://cabforum.org/wp-content/uploads/Chunghwatelecom201503cabforumV4.pdf.

I explained the rollover certificate process outlined in RFC 4210 by signing the old public key with the new private key and the new public key with the old private key. I also gave the definition of Self-issued certificates (Self-issued certificates are generated to support changes in policy or operations. So there will be values in certificate policies extension filed of self-issued certificates) and Self-signed certificates (CA certificates in which the issuer and subject are the same entity. For a Root CA self-signed certficae, there will be no value in certificate policies extension.) as RFC 5280. Following RFC 5280 6.1, a certificate is self-issued if the same DN appears in the subject and issuer fields. The Taiwanese Government Root CA (GRCA) has switched over from SHA1 to SHA256 (in 2012), but we have encountered IIS issues following the processes found in the RFCs. See Slide pp.8-pp.13. IIS 7 falsely treated GRCA’s Self-Issued certificate (new with old) as a Self-Signed certificate, because it has the same issuer and subject name. We found SSL Cert –> GCA Cert –> new-with-old GRCA Cert –> old GRCA cert in IIS side, but IIS only sends SSL Cert –> GCA Cert to client. For Mozilla Firefox, it uses its own trust list and it only trusts old GRCA and new GRCA is waiting to be built in NSS. So there are lots of complaints of Firefox users connected to IIS sites. Because Windows clients support AIA chasing there are less chaining problems.


Chunghwa Telecom requested Microsoft to solve the bug of IIS ASAP through Premium support last spring. But until now Microsoft IIS team has not yet solve the bug.

Chunghwa Telecom suggested to make AIA mandatory and browsers must support fetching intermediate certificates through AIA. Supporting AIA will also reduce some web site administrators forget to install intermediate certificates to their server follow CAs or web server’s manuals. (In SSL protocol, SSL servers should send intermediate certificate & SSL certificate to SSL client)


It seems that Mozilla Firefox has not yet suppot AIA. So the best solution to solve the bug is to include the new Taiwna Government Root Certification Authority root certificate in Mozilla NSS, and turn on the Websites and Email trust bits. It will significantly reduces complaints from Mozilla User and administrators of Taiwan government entities's websites that use IIS.

In CA/Browser Form 34th F2F meeting minutes, There are [ Additionally, Brian Smith commented separately via email, “It is also possible, and recommended, for the rollover certificate to be added to Firefox’s certificate store. Then Firefox will be able to use it even if IIS doesn’t send it.”]

[Jakob Bohm]

You have made a fundamental technical mistake.

Using two different public keys with the same exact full distinguished
name is generally not expected to work. Some implementations may use
additional checks (such as the key identifier or certificate serial
number) to disambiguate, but this is generally known to be a frequent
cause of errors and bugs, such as the ones observed in your
presentation.

All in all, the "self-issued but not self-signed" concept never worked
and is effectively dead.

Asking for mandatory AIA is a bad solution.

Maybe you need to generate a new third generation "Taiwan-GRCA 2016"
root with a unique name, along with the needed "2016 with 2016", "2016
with 2012" and "2016 with original" certificates, such that web servers
can send at least one valid chain. IIS could send the chain that ends
in "2016 with original" (by installing that cert to the
machine\Intermediaries part of the Windows certificate store and not
installing the "2016 with 2016" cert on the IIS server), while Apache
can send a list that ends with all 3 2016 certificates. The AIA cert
download URL in certificates issued by 2016 would probably have to
return "2016 with 2012", while the AIA cert download URL in "2016 with
2012" would return "2012 with original", this is based on the assumption
that AIA-supporting browsers will check for trusted certs before
attempting AIA download and that the most widespread
AIA-supporting browsers will not be confused by the self-issued "2012
with original" cert.

To ensure a pure SHA-256 chain when chaining all the way back to the
original, it is advisable (if it can be done securely, as is not the
case with ECC and DSA), for the "2012 with original" and "2016 with
original" certificates to be signed using SHA-256 and the original key
pair.

When providing repudiation/revocation checks for end certificates
issued using SHA-1 by the original private key, these checks should be
signed by dedicated SHA-1 "CRL signing" and "OCSP signing" certificates
issued using SHA-1 by the original private key, which (under the
current twisted CA/B forum rules) implies that the "original with 2012"
certificate needs to be revoked and that a special CA/B forum
permission is needed to issue/renew the revocation SHA-1 certificates
while the original certificate is still trusted by any CA/B member
browser. Certificates issued by the original key pair using SHA-256,
such as, usually, the "2012 with original" and "2016 with original"
certificates) should point to different CRL and OCSP URLs that are
signed with SHA-256, but still reports all the old revoked SHA-1 certs.

P.S.

Be careful when revoking the "original with 2012" certificate, when
GlobalSign recently did the same with their similar "R1 with R3"
certificate, it triggered a bug in their OCSP server solution which
suddenly told all clients that a lot of other certificates were also
revoked.

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

[Peter Bowen]

On Sat, Dec 3, 2016 at 9:22 AM, Jakob Bohm <jb-mo...@wisemo.com> wrote:
> On 03/12/2016 09:34, lcchen...@gmail.com wrote:
>>

> Using two different public keys with the same exact full distinguished
> name is generally not expected to work. Some implementations may use
> additional checks (such as the key identifier or certificate serial
> number) to disambiguate, but this is generally known to be a frequent
> cause of errors and bugs, such as the ones observed in your
> presentation.
>
> All in all, the "self-issued but not self-signed" concept never worked
> and is effectively dead.

I agree with Jakob here. As was recently pointed out in a discussion
on the path length constraint for CAs, allowing self-issued but not
self-signed opens up unexpected vulnerabilities.

Mozilla should require that there be exactly one public key associated
with each CA Distinguished Name. Key rotation should be accompanied
by DN rotation.

> Maybe you need to generate a new third generation "Taiwan-GRCA 2016"

> root with a unique name, along with the needed [...] certificates, such that web servers

> can send at least one valid chain.

I think that is an excellent suggestion.

As to the inclusion request, I think Mozilla should reject this
request and add a clear rule to the Mozilla CA policy that each CA
must have a unique DN. The DN should be a primary key for the trust
store and no two entries should have the same DN.

Thanks,
Peter

[Peter Bowen]

On Thu, Sep 22, 2016 at 12:57 AM, <hor...@gmail.com> wrote:
> Peter Bowen於 2016年9月20日星期二 UTC+8下午11時53分29秒寫道：

> GRCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2016.pdf)
>
> GCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2016.pdf)
> GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2015.pdf)
>
> XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Report_2016.pdf)
>
> HCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2015.pdf)
>
> MOEACA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2015.pdf)
>
> MOICA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2015.pdf)

I see the following subordinate CAs under the two Government Root CAs:

C=TW, O=行政院, OU=內政部憑證管理中心
C=TW, O=行政院, OU=工商憑證管理中心
C=TW, O=行政院, OU=政府憑證管理中心
C=TW, O=行政院, OU=政府測試憑證管理中心
C=TW, O=行政院, OU=組織及團體憑證管理中心
C=TW, O=行政院, OU=醫事憑證管理中心
C=TW, O=行政院, OU=內政部憑證管理中心
C=TW, O=行政院, OU=內政部憑證管理中心
C=TW, O=行政院, OU=工商憑證管理中心
C=TW, O=行政院, OU=政府憑證管理中心
C=TW, O=行政院, OU=組織及團體憑證管理中心

None of the CA certificates have an EKU extension, so all are capable
of issuing server authentication certificates. Therefore each of
these should have a BR audit if the websites bit is going to be
enabled.

Thanks,
Peter

[Peter Gutmann]

lcchen...@gmail.com <lcchen...@gmail.com> writes:

>I explained the rollover certificate process outlined in RFC 4210 by signing
>the old public key with the new private key and the new public key with the
>old private key.

Uhh, that stuff was a gedanken experiment dreamed up by some folks in PKIX,
alongside things like PKIX path-kludge certificates, not something you're
supposed to rely on in real life. I'd be really surprised if any generic
implementation actually handled those things the way PKIX imagined they will.
I certainly wouldn't risk deploying one of those things on the assumption that
it'll be handled properly. The path-kludge in particular looks like something
that was designed to make PKIs break.

Peter.

[capuc...@gmail.com]

Jakob Bohm於 2016年12月4日星期日 UTC+8上午1時23分16秒寫道：

>
> You have made a fundamental technical mistake.

I do not understand that why do you said that we made a fundamental technical mistake? As I had participated in drafting RFC 5280, I am sure that our implementation fully conforms to RFC 5280 and of course the original ITU-T X.509 standards. Do you mean that our conforming to the standards is a fundamental mistake? If so, whay there needs standards?

>
> Using two different public keys with the same exact full distinguished
> name is generally not expected to work. Some implementations may use
> additional checks (such as the key identifier or certificate serial
> number) to disambiguate, but this is generally known to be a frequent
> cause of errors and bugs, such as the ones observed in your
> presentation.

We understand that many commercial CAs change their issuer names of root CA whenever they re-keying because in the early days they were not sure whether certificate-using softwares (such browsers) have fully implemented certification path validation algorithms specified in RFC 5280 or the original X.509 standard and therefore they think this is the safest way to make sure certificate-using softwares to correctly chain up to the correct generation of root certificates. However, that does not means our PKIX (RFC-5280) conforimg implementation will cause errors or bugs to current implementations of browsers.

Actually, in RFC 5280 as well as the original X.509 standard, the recommended official way to distinguish the different generation of CA certificates is by using the chaining of the Issuer Key Identifier extension and Subject Key Identifier extension (as you mentioned) in certification path processing.

So, whay not juest test whether our implementation will cause errors to the current implememtation of Mozilla NSS libraries?

Actually, Microsoft had already accepted our second generation of GRCA self-signed certificate around 1 year ago, we have not encountered certificate chaining ambiguity issue that you worried. I think that is because Microsoft's current CryptoAPI is in some good degree of comforming to PKIX standard.

Please note that in the official web page of NSS (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Overview), Mozilla claims that the NSS is interoperable with PKIX certificate and CRL profiles. Therefore, I have confidence that Mozilla NSS can peacefully live with our PKIX conforming implementation of CA.

>
> All in all, the "self-issued but not self-signed" concept never worked
> and is effectively dead.
>

I would suggest that you should not be so assured. Please note that performing key-rollover by using self-issued certificates is mandatory for all Country Signing CAs (CSCA) of ICAO eMRTD (e.g. ePassport, or eID). It is that many commercial CAs choose to not implemented the key-rollover process suggestted by the PKXI standard or the origonal X.509 standard but that does not mean the concept never worked and is effectively dead. There are still many governmental CAs choose to fully conform to the standards as the best as they can.

> Asking for mandatory AIA is a bad solution.
>

We are noe asking for mandatory AIA implementation. We are here to asking Mozilla to include our second generaion self-signed root certificate of Taiwan GRCA, whcih conforms to PKIX standard, to the NSS trust list.

Thanks for your reminding. We undertand the key-rollover process well. After key rollover, we always keep the old private key of CA to contine issuing CRLs and OCSP responder certificates (short lived) untill all the end-entity certificatres that issued under the old CA private key expire.

> 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

Wen-Cheng Wang

[王文正]

Peter Bowen於 2016年12月4日星期日 UTC+8上午1時43分00秒寫道：

> On Sat, Dec 3, 2016 at 9:22 AM, Jakob Bohm wrote:
> >
> > Using two different public keys with the same exact full distinguished
> > name is generally not expected to work. Some implementations may use
> > additional checks (such as the key identifier or certificate serial
> > number) to disambiguate, but this is generally known to be a frequent
> > cause of errors and bugs, such as the ones observed in your
> > presentation.
> >
> > All in all, the "self-issued but not self-signed" concept never worked
> > and is effectively dead.
>
> I agree with Jakob here. As was recently pointed out in a discussion
> on the path length constraint for CAs, allowing self-issued but not
> self-signed opens up unexpected vulnerabilities.
>
> Mozilla should require that there be exactly one public key associated
> with each CA Distinguished Name. Key rotation should be accompanied
> by DN rotation.
>

Requiring that Key rollover must be accompanied by DN rotation will contradict with the PKIX standard and the original X.509 standard. In the PKIX standard and the original X.509 standard, the recommended way is to use Authority Key Identifier and Subject Key Identifier chaining for distinguishing different generation of cert/CRL signing keys but with the same issuer DN. If Mozilla makes the requirement k that ey rollover must be accompanied by DN rotation, it means Mozilla NSS trust list will completely rule out those CAs conforming to the PKIX standard. If so, I do know how Mozilla can claim that the NSS is interoperable with PKIX Certificate and CRL profile?

> > Maybe you need to generate a new third generation "Taiwan-GRCA 2016"
> > root with a unique name, along with the needed [...] certificates, such that web servers
> > can send at least one valid chain.
>
> I think that is an excellent suggestion.
>
> As to the inclusion request, I think Mozilla should reject this
> request and add a clear rule to the Mozilla CA policy that each CA
> must have a unique DN. The DN should be a primary key for the trust
> store and no two entries should have the same DN.

As far as I known, currently the Mozilla CA policy does no require CAs to change their DNs whenever performing key rollover. I believe that Mozilla should not make this kind of requirement in the CA policy because that will contradict with the PKIX standard as well as the original ITU-T X.509 standard.

>
> Thanks,
> Peter

Wen-Cheng Wang
Chief PKI Product Manager
Chunghwa Telecom Co., Ltd.

[Peter Gutmann]

capuc...@gmail.com <capuc...@gmail.com> writes:

>However, that does not means our PKIX (RFC-5280) conforimg implementation
>will cause errors or bugs to current implementations of browsers.

Given all the bizarre stuff that ended up in the PKIX spec, it would be quite
easy to create a fully PKIX-compliant cert that had all manner of strange and
unexpected interactions with browsers (see my previous message for examples).
The skill required for deploying certs is to know (or at least have a general
idea of) what will happen to them in the wild, not to assume that whatever
peculiar thing the PKIX spec says is actually implemented by anyone.

>Actually, in RFC 5280 as well as the original X.509 standard, the recommended
>official way to distinguish the different generation of CA certificates is by
>using the chaining of the Issuer Key Identifier extension and Subject Key
>Identifier extension (as you mentioned) in certification path processing.

OK, that's one of the less crazy things in the spec, but it still doesn't
guarantee that much, if anything, does it that way. In practice, you chain by
DN, not by key ID.

Peter.

[Gervase Markham]

Hi Wen-Cheng,

On 04/12/16 06:12, 王文正 wrote:
> Requiring that Key rollover must be accompanied by DN rotation will
> contradict with the PKIX standard and the original X.509 standard.

Leaving aside the particular situation we are in, in general the Web PKI
uses X.509 and other standards as a guide, but if something doesn't
work, or we stop allowing it for security reasons, that's just the way
it is and that needs to be accepted. Take, for example, non-critical
name constraints. Not allowed by the RFC, but used in the Web PKI.

I note also that Mozilla's root store policy says:

"This also includes (but again is not limited to) cases where we believe
that including a CA certificate (or setting its "trust bits" in a
particular way) might cause technical problems with the operation of our
software..."

If what you are trying to do doesn't work in our software, it may end up
that we just shrug our shoulders and tell you to do something else.
That's not definite, but it is a possible outcome you need to be
prepared for.

> If so, I do know how Mozilla can claim that the NSS is
> interoperable with PKIX Certificate and CRL profile?

If you are right, we may just have to stop claiming that :-)

Gerv

[Gervase Markham]

On 03/12/16 17:42, Peter Bowen wrote:
> As to the inclusion request, I think Mozilla should reject this
> request and add a clear rule to the Mozilla CA policy that each CA
> must have a unique DN. The DN should be a primary key for the trust
> store and no two entries should have the same DN.

Just to help me be clear: the request is for the inclusion of a root
with the same DN as a previous root, which will still be included after
the addition? Or the problem with duplicate DNs occurs further down the
hierarchy?

Does Firefox build cert chains using DNs, or using Key Identifiers as
Wen-Cheng says it should? I assume it's the former, but want to check.

Gerv

[王文正]

Gervase Markham於 2016年12月4日星期日 UTC+8下午6時18分48秒寫道：

> Hi Wen-Cheng,
>
> On 04/12/16 06:12, 王文正 wrote:
> > Requiring that Key rollover must be accompanied by DN rotation will
> > contradict with the PKIX standard and the original X.509 standard.
>
> Leaving aside the particular situation we are in, in general the Web PKI
> uses X.509 and other standards as a guide, but if something doesn't
> work, or we stop allowing it for security reasons, that's just the way
> it is and that needs to be accepted. Take, for example, non-critical
> name constraints. Not allowed by the RFC, but used in the Web PKI.

Well, I believe that retain the same DN for the root CA after performing key rollover will not cause security issues. If it will cause security issues, Mozilla certainly has the right to reject our root certificate.

If you are aware of any security issue that might cause by a root CA retaining the same DN, please clearly describe what kind of security issue it will cause, and then I will submit an technical errata report to PKIX to ask for amending RFC 5280.

>
> I note also that Mozilla's root store policy says:
>
> "This also includes (but again is not limited to) cases where we believe
> that including a CA certificate (or setting its "trust bits" in a
> particular way) might cause technical problems with the operation of our
> software..."
>
> If what you are trying to do doesn't work in our software, it may end up
> that we just shrug our shoulders and tell you to do something else.
> That's not definite, but it is a possible outcome you need to be
> prepared for.
>

That is fair. If our implementation does not work with your software, you certainly has the right to not accept our root certificate. Let's just test it and we will know if it works.

> > If so, I do know how Mozilla can claim that the NSS is
> > interoperable with PKIX Certificate and CRL profile?
>
> If you are right, we may just have to stop claiming that :-)

Well, on the other hand, you might embrace more positive thinking. This can be a chance to improve the certification path processing algorithm of Mozilla NSS to make it truly interoperable with PKIX Certificate and CRL profile :-)

>
> Gerv

Wen-Cheng Wang

[王文正]

Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：

> On 03/12/16 17:42, Peter Bowen wrote:
> > As to the inclusion request, I think Mozilla should reject this
> > request and add a clear rule to the Mozilla CA policy that each CA
> > must have a unique DN. The DN should be a primary key for the trust
> > store and no two entries should have the same DN.
>
> Just to help me be clear: the request is for the inclusion of a root
> with the same DN as a previous root, which will still be included after
> the addition? Or the problem with duplicate DNs occurs further down the
> hierarchy?

Our request is for the inclusion of a root with the same DN as a previous root.

In our Government PKI, we have a national LDAP tree and all the entities (including the root CA, subordinate CAs, and end entities) have their own unique DNs in the directory tree. Since our Government Root CA (GRCA) is a permanent node in our national LDAP tree, it has certainly been assigned an unique DN. If we change the DN of our Government Root CA (GRCA) each time it re-key, that will generate multiple nodes of our Government Root CA with different DNs in our national LDAP tree and that will be quite confusing.

Wen-Cheng Wang

[Peter Bowen]

On Sun, Dec 4, 2016 at 7:26 AM, 王文正 <capuc...@gmail.com> wrote:
> Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道：

>> On 03/12/16 17:42, Peter Bowen wrote:
>> > As to the inclusion request, I think Mozilla should reject this
>> > request and add a clear rule to the Mozilla CA policy that each CA
>> > must have a unique DN. The DN should be a primary key for the trust
>> > store and no two entries should have the same DN.
>>
>> Just to help me be clear: the request is for the inclusion of a root
>> with the same DN as a previous root, which will still be included after
>> the addition? Or the problem with duplicate DNs occurs further down the
>> hierarchy?
>

> Our request is for the inclusion of a root with the same DN as a previous root.
>
> In our Government PKI, we have a national LDAP tree and all the entities (including the root CA, subordinate CAs, and end entities) have their own unique DNs in the directory tree. Since our Government Root CA (GRCA) is a permanent node in our national LDAP tree, it has certainly been assigned an unique DN. If we change the DN of our Government Root CA (GRCA) each time it re-key, that will generate multiple nodes of our Government Root CA with different DNs in our national LDAP tree and that will be quite confusing.

Based on the publicly available data, it looks like you have multiple
sets of CAs with the same DN in your tree. For example MOEACA:
https://crt.sh/?caid=13914 and https://crt.sh/?caid=13162 have the
same DN and have different keys.

I think the larger issue is that you don't have BR audits for the
subordinate CAs.

Thanks,
Peter

[Wen-Cheng Wang]

On Sunday, December 4, 2016 at 5:58:56 PM UTC+8, Peter Gutmann wrote:

> Wen-Cheng Wang writes:
>
> >However, that does not means our PKIX (RFC-5280) conforimg implementation
> >will cause errors or bugs to current implementations of browsers.
>
> Given all the bizarre stuff that ended up in the PKIX spec, it would be quite
> easy to create a fully PKIX-compliant cert that had all manner of strange and
> unexpected interactions with browsers (see my previous message for examples).
> The skill required for deploying certs is to know (or at least have a general
> idea of) what will happen to them in the wild, not to assume that whatever
> peculiar thing the PKIX spec says is actually implemented by anyone.

Actually, we have tested the capabilities of many browsers in the wild and found they can live peacefully with our PKIX-compliant root certs. They are not so weak as you might think.

What I do not understand is why the first responses of people here seems in a hurry to reject a PKIX-compliant root cert? Currently, there is no rule in Mozilla CA policy that forbid a root CA to retain its DN after re-key. What we need to do here is simply to test whether Mozilla NSS can live peacefully with our PKIX-compliant root certs. If it does, why not accept it?

>
> >Actually, in RFC 5280 as well as the original X.509 standard, the recommended
> >official way to distinguish the different generation of CA certificates is by
> >using the chaining of the Issuer Key Identifier extension and Subject Key
> >Identifier extension (as you mentioned) in certification path processing.
>
> OK, that's one of the less crazy things in the spec, but it still doesn't
> guarantee that much, if anything, does it that way. In practice, you chain by
> DN, not by key ID.

Of course we chain up the certification path by DN. The Authority Key Identifier extension and the Subject Key Identifier extension are to be used to facilitate choosing different generation of CA certificates. I do not mean that the certification path is chained up by key ID.

Wen-Cheng Wang

[Wen-Cheng Wang]

On Sunday, December 4, 2016 at 11:56:13 PM UTC+8, Peter Bowen wrote:

You are right, there are several subordinate CAs under our Government Root CA. Our Government Root CA and all its subordinate have WebTrust for CA audits. However, among those subordinate CAs, only GCA will issue SSL certificates. Therefore, only Government Root CA and GCA have SSL BR audits. Since currently all other subordinate CAs so not issue SSL certificates, it is certainly not possible for them to have SSL BR audits.

PS: There is another subordinate CA named HCA that used to issue SSL certificates too, but HCA had stopped issuing SSL certificates. Therefore, currently GCA is the only subordinate CA that will issue SSL certificates.

Wen-Cheng Wang

[Peter Gutmann]

Wen-Cheng Wang <capuc...@gmail.com> writes:

>Actually, we have tested the capabilities of many browsers in the wild and
>found they can live peacefully with our PKIX-compliant root certs.

Ah, OK. That's the right way to do it.

>They are not so weak as you might think.

I bet I can create PKIX-compliant certs (specifically, cert chains) that would
break any browser :-). But yeah, if you go and test each browser you can
create lowest-common-denominator certs that should work in general.

Peter.

[Gervase Markham]

On 04/12/16 08:17, Wen-Cheng Wang wrote:
> You are wight, there are several subordinate CAs under our Government

> Root CA. Our Government Root CA and all its subordinate have WebTrust
> for CA audits. However, among those subordinate CAs, only GCA will
> issue SSL certificates. Therefore, only Government Root CA and GCA
> have SSL BR audits. Since currently all other subordinate CAs so not
> issue SSL certificates, it is certainly not possible for them to have
> SSL BR audits.

Not possible technically, or not possible by policy?

As I understand it, Peter is pointing out that these subordinate CAs are
not constrained, and so could issue SSL certificates which would be
trusted in any browser which trusted the root. Therefore, their policies
and practices have to fall under Mozilla's root policy.

We plan to make an update to the policy to make it very clear that the
important criterion is technical capability, not intent. See:
https://github.com/mozilla/pkipolicy/issues/27

Gerv

[Jakob Bohm]

On 04/12/2016 06:00, capuc...@gmail.com wrote:
> Jakob Bohm於 2016年12月4日星期日 UTC+8上午1時23分16秒寫道：
>>
>> You have made a fundamental technical mistake.
> I do not understand that why do you said that we made a fundamental technical mistake? As I had participated in drafting RFC 5280, I am sure that our implementation fully conforms to RFC 5280 and of course the original ITU-T X.509 standards. Do you mean that our conforming to the standards is a fundamental mistake? If so, whay there needs standards?
>

The mistake was to use a part of those standards which is often
problematic in the real world. For example, according to your
presentation, when IIS builds server certificate chains to send to
clients, it compares only the DN, causing problems when non-AIA-
downloading browsers visit IIS-powered sites with GCA certificates.

It is a technical mistake in believing all software handles multiple
certificates with the same DN, not a legal mistake in reading a
document saying this should be permitted.

>> Asking for mandatory AIA is a bad solution.
>>
> We are noe asking for mandatory AIA implementation. We are here to asking Mozilla to include our second generaion self-signed root certificate of Taiwan GRCA, whcih conforms to PKIX standard, to the NSS trust list.
>

Your previous post said:

> Chunghwa Telecom suggested to make AIA mandatory and browsers must
> support fetching intermediate certificates through AIA. Supporting
> AIA will also reduce some web site administrators forget to install
> intermediate certificates to their server follow CAs or web server’s
> manuals. (In SSL protocol, SSL servers should send intermediate
> certificate & SSL certificate to SSL client)

[Wen-Cheng Wang]

Hi Gervase,

On Monday, December 5, 2016 at 9:00:53 PM UTC+8, Gervase Markham wrote:
> On 04/12/16 08:17, Wen-Cheng Wang wrote:
> > You are wight, there are several subordinate CAs under our Government
> > Root CA. Our Government Root CA and all its subordinate have WebTrust
> > for CA audits. However, among those subordinate CAs, only GCA will
> > issue SSL certificates. Therefore, only Government Root CA and GCA
> > have SSL BR audits. Since currently all other subordinate CAs so not
> > issue SSL certificates, it is certainly not possible for them to have
> > SSL BR audits.
>
> Not possible technically, or not possible by policy?
>

I mean BR Audit is specifically for CAs that provide SSL certificates. Therefore, it is not possible to conduct on those subordinate CAs that do not provide SSL certificates, and it is certainly not possible for them to get the WebTrust SSL BR seals. That is why in our Government PKI, the WebTrust SSL BR seal only covers GRCA (the root CA) and GCA (which provides SSL certificates). However, I would like to emphasize that the WebTrust for CA seal cover the whole Government PKI (including the root CA and all its subordinate CAs).

> As I understand it, Peter is pointing out that these subordinate CAs are
> not constrained, and so could issue SSL certificates which would be
> trusted in any browser which trusted the root. Therefore, their policies
> and practices have to fall under Mozilla's root policy.
>

As for how to make sure policies and practices of all our CAs fall under Mozilla's root policy, every time we received Kathleen's notification about the revision of Mozilla's root policy, we reviewed our CP of the Government PKI and CPSs of all CAs seriously. If necessary, we will make amendments to our CP and CPSs so that they can aligned with Mozilla's root policy and we will reply what we plan to do for responding the change of Mozilla's root policy to Kathleen. Since we have conducted WebTrust for CA audits on the whole Government PKI (including the root CA and all its subordinate CAs), the audit results can assure our CAs are all compliant to Mozilla's root policy.

Wen-Cheng Wang

[Wen-Cheng Wang]

Hi Jacob,

I think you get confused by My colleague Li-Chun's email because he mentioned a lot about using self-issued certificates for key-rollover, AIA certificate chaining support, and the bug of Microsoft IIS (note: not IE browser) in handling self-issued certificates. All these are actually off-topic. We are sorry if his email confused you.

Here I would like to clarify that we are not here to asking for supporting self-issued certificates or AIA certificate chaining. We are here to simply request Mozilla to accept our second generation of Government Root CA certificate.

Currently, our first generation of Government Root CA certificate has alreading been in the trust list of Mozilla. After Mozilla accepting our second generation of Government Root CA certificate, our certificate chains for SSL will look like the following:

1. Government Root CA (first generation) --> GCA (first generation) --> SSL Cert
2. Government Root CA (second generation) --> GCA (second generation) --> SSL Cert

This is the same as the situation of other root CAs performing key-rollover.

One thing different with what other commercial CAs is that we do not change the issuer DN when our root CA perform key-rollover. I have already explain a lot of this in this discussion thread. According our tests, using the same issuer DN between generations of root CA certificates actually will not cause problem for browsers to perform certificate chaining. Therefore, please do not worry about it.

>
> The mistake was to use a part of those standards which is often
> problematic in the real world. For example, according to your
> presentation, when IIS builds server certificate chains to send to
> clients, it compares only the DN, causing problems when non-AIA-
> downloading browsers visit IIS-powered sites with GCA certificates.

Since this is off-topic, I would not like to spend a lot time and space to discuss self-issued certificate and AIA issues here. However, to make a quick clarification, browsers do not have problem if the certificate chain contains self-issued certificates. Actually, even Microsoft's IE can handle certificate chains containing self-issued certificates. It is Microsoft's IIS can not correctly send the certificate chain to the client side. Other https server such aa Apache have no problem with certificate chains containing self-issued certificates.

>
> It is a technical mistake in believing all software handles multiple
> certificates with the same DN, not a legal mistake in reading a
> document saying this should be permitted.
>

As I have mentioned, browsers actually do not have problem with the same issuer DN between generations of root CA certificates.

Wen-Cheng Wang

[Gervase Markham]

On 05/12/16 21:10, Wen-Cheng Wang wrote:
> I mean BR Audit is specifically for CAs that provide SSL
> certificates. Therefore, it is not possible to conduct on those
> subordinate CAs that do not provide SSL certificates,

AIUI, that's not actually true. As we found out recently when discussing
another CA whose name escapes me, it's possible to include a subordinate
CA in an audit even if it's not issuing any certificates.

> As for how to make sure policies and practices of all our CAs fall
> under Mozilla's root policy, every time we received Kathleen's
> notification about the revision of Mozilla's root policy, we reviewed
> our CP of the Government PKI and CPSs of all CAs seriously. If
> necessary, we will make amendments to our CP and CPSs so that they
> can aligned with Mozilla's root policy and we will reply what we plan
> to do for responding the change of Mozilla's root policy to Kathleen.
> Since we have conducted WebTrust for CA audits on the whole
> Government PKI (including the root CA and all its subordinate CAs),
> the audit results can assure our CAs are all compliant to Mozilla's
> root policy.

Our root policy also requires (or will soon require) a BR audit to cover
all sub-CAs technically capable of issuing server certs.

Gerv

[Brian Smith]

Gervase Markham <ge...@mozilla.org> wrote:
> Just to help me be clear: the request is for the inclusion of a root
> with the same DN as a previous root, which will still be included after
> the addition? Or the problem with duplicate DNs occurs further down the
> hierarchy?

Some people claimed some software may be unable to cope with two
different CA certificates with the same subject DNs. Nobody claimed
that Firefox is unable to cope with two CA certificates having the
same subject DN. It should work fine in Firefox because Firefox will
attempt every CA cert it finds with the same DN.

One caveat: If there are "too many" CA certificates with the same
subject DN, Firefox will spend a very long time searching through
them. This is a bug in Firefox that's already on file.

> Does Firefox build cert chains using DNs, or using Key Identifiers as
> Wen-Cheng says it should? I assume it's the former, but want to check.

Firefox doesn't even parse the key identifiers. Using the key
identifiers are only helpful when a CA does the thing that this
particular CA does, using the same subject DN for multiple CA
certificates, to prevent the "too many" problem mentioned above.

I'm unconvinced that it is worthwhile to add the Key Identifier stuff
just to accommodate this one public CA plus any private CAs that do
similarly. I think it's better to ask this CA to instead do things the
way all the other public CAs do (AFAIK). In other words, this is kind
of where the Web PKI diverges from PKIX.

However, the CA changing its practices could be done on a
going-forward basis; the existing instances shouldn't be problematic
and so I don't think they should be excluded on the basis of what they
already did.

Cheers,
Brian
--
https://briansmith.org/

[Erwann Abalea]

Bonsoir,

Le mardi 6 décembre 2016 09:31:48 UTC+1, Wen-Cheng Wang a écrit :
> Hi Jacob,
>
> I think you get confused by My colleague Li-Chun's email because he mentioned a lot about using self-issued certificates for key-rollover, AIA certificate chaining support, and the bug of Microsoft IIS (note: not IE browser) in handling self-issued certificates. All these are actually off-topic. We are sorry if his email confused you.

I don't think there is a bug in IIS here. IIRC, you discovered that IIS doesn't send the self-issued certificate when loaded with the 2 self-signed root certs and the self-issued cert (1st gen signing 2nd gen). And IIS' behaviour is right, in that it doesn't know if the browser will need this link certificate. IIRC again, what was proposed for you is that you declare the 2nd gen self-signed cert as untrusted on your side, to force IIS to send the link.

> Here I would like to clarify that we are not here to asking for supporting self-issued certificates or AIA certificate chaining. We are here to simply request Mozilla to accept our second generation of Government Root CA certificate.
>
> Currently, our first generation of Government Root CA certificate has alreading been in the trust list of Mozilla. After Mozilla accepting our second generation of Government Root CA certificate, our certificate chains for SSL will look like the following:
>
> 1. Government Root CA (first generation) --> GCA (first generation) --> SSL Cert
> 2. Government Root CA (second generation) --> GCA (second generation) --> SSL Cert

You're playing with corner cases of X.509/PKIX. You're right that on paper, it's clearly defined, it works, etc. In practice, it may not work, and even if you can blame and shame a non completely conformant implementation refusing this scheme, I don't think it's a situation you should be comfortable in as a CA.

Talking about your duties when playing with such renewals, you already know that the population under GCA 1st gen and GCA 2nd gen is the same with regard to generated serial numbers and CRLs produced (the content of the CRL chaining to GCA 1st gen MUST be identical to the content of the CRL chaining to GCA 2nd gen, unless you implement CRL partitioning).

And the situation gets weirder with the Root. In X.509, GDCA 1st gen and GDCA 2nd gen are a single CA (serial numbers assigned to issued certs, CRLs, etc). And there's a difference here between RFC5280 and X.509. In RFC5280, the CRL chaining to GDCA 1st gen can't give a valid revocation result for a certificate chaining to GDCA 2nd gen, and thus the set of serial numbers for certs issued by each gen of GDCA may or may not be disjoint. It's an unclear area of RFC5280, and it's not fun to sit in here.

>From what I see, you're doing it correctly from an X.509 point of view. Each GCA gen produces its partitioned CRL plus an unpartitioned complete one, both complete ones are identical in content (except a few seconds delta in the thisUpdate field, unimportant). And I found 3 CRLs issued under GDCA, with identical contents. That should also work if RFC5280 rules are followed.

> This is the same as the situation of other root CAs performing key-rollover.

It's not that common. I know about ICAO MRTD certs (worked on it for a few years, not that long ago), it's a real mess, and it's not a valid example of successful PKI deployment.

> One thing different with what other commercial CAs is that we do not change the issuer DN when our root CA perform key-rollover. I have already explain a lot of this in this discussion thread. According our tests, using the same issuer DN between generations of root CA certificates actually will not cause problem for browsers to perform certificate chaining. Therefore, please do not worry about it.
>
> >
> > The mistake was to use a part of those standards which is often
> > problematic in the real world. For example, according to your
> > presentation, when IIS builds server certificate chains to send to
> > clients, it compares only the DN, causing problems when non-AIA-
> > downloading browsers visit IIS-powered sites with GCA certificates.
>
> Since this is off-topic, I would not like to spend a lot time and space to discuss self-issued certificate and AIA issues here. However, to make a quick clarification, browsers do not have problem if the certificate chain contains self-issued certificates. Actually, even Microsoft's IE can handle certificate chains containing self-issued certificates. It is Microsoft's IIS can not correctly send the certificate chain to the client side.

Mozilla::pkix doesn't know about self-issued certificates. The library just considers such a certificate as a subordinate CA cert. It happens to work in your specific situation.

> Other https server such aa Apache have no problem with certificate chains containing self-issued certificates.

That may not be true in recent versions, depending on how you configure your server. But again, off-topic.

[Wen-Cheng Wang]

On Thursday, December 8, 2016 at 10:21:53 PM UTC+2, Gervase Markham wrote:
> On 05/12/16 21:10, Wen-Cheng Wang wrote:
> > I mean BR Audit is specifically for CAs that provide SSL
> > certificates. Therefore, it is not possible to conduct on those
> > subordinate CAs that do not provide SSL certificates,
>
> AIUI, that's not actually true. As we found out recently when discussing
> another CA whose name escapes me, it's possible to include a subordinate
> CA in an audit even if it's not issuing any certificates.

To my understanding, if a CA has not yet issuing any certificate, it is at most to perform "readiness assessment" on that CA because there is still no records or evidences to proof the conformity.

> > As for how to make sure policies and practices of all our CAs fall
> > under Mozilla's root policy, every time we received Kathleen's
> > notification about the revision of Mozilla's root policy, we reviewed
> > our CP of the Government PKI and CPSs of all CAs seriously. If
> > necessary, we will make amendments to our CP and CPSs so that they
> > can aligned with Mozilla's root policy and we will reply what we plan
> > to do for responding the change of Mozilla's root policy to Kathleen.
> > Since we have conducted WebTrust for CA audits on the whole
> > Government PKI (including the root CA and all its subordinate CAs),
> > the audit results can assure our CAs are all compliant to Mozilla's
> > root policy.
>
> Our root policy also requires (or will soon require) a BR audit to cover
> all sub-CAs technically capable of issuing server certs.

Currently, in our Government PKI, GCA is the only sub-CA approved, in its CPS, by the government Policy Management Authority (PMA) to issuing SSL certificates. For other subordinate CAs, if they want to issue SSL certificates, they must amend their CPSs and get approved by the government PMA. For subordinate CAs that currently does not intend to issuing SSL certificates, they have no SSL certificate practices or procedures to be disclosed in their CPSs. In such situations, we think it will be not much meaningful to conduct the BR audit on them. After all, the main scope of the BR audit is to exam the conformity of SSL certificate practices or procedures.

Please see also in the WebTrust for Certification Authorities - Audit Applicability Matrix (http://www.webtrust.org/principles-and-criteria/item83665.pdf), it says that the BR Audit (WebTrust for CA - SSL Baseline + Network) is not required for Government CAs or Commercial CAs which only issuing certificates for all other uses.

Wen-Cheng Wang

[Wen-Cheng Wang]

On Friday, December 9, 2016 at 1:43:27 AM UTC+2, Brian Smith wrote:
> Some people claimed some software may be unable to cope with two
> different CA certificates with the same subject DNs. Nobody claimed
> that Firefox is unable to cope with two CA certificates having the
> same subject DN. It should work fine in Firefox because Firefox will
> attempt every CA cert it finds with the same DN.

Thanks a lot for clarifying this.

> One caveat: If there are "too many" CA certificates with the same
> subject DN, Firefox will spend a very long time searching through
> them. This is a bug in Firefox that's already on file.

We will maintains at most two generations of Root CA certificates with the same DN in Mozilla/firefox's trust list. I believe that we will not cause such kind of "too many" issue.

> I'm unconvinced that it is worthwhile to add the Key Identifier stuff
> just to accommodate this one public CA plus any private CAs that do
> similarly. I think it's better to ask this CA to instead do things the
> way all the other public CAs do (AFAIK). In other words, this is kind
> of where the Web PKI diverges from PKIX.

Believe me, now we really take consideration that in the next generation of our Government Root CA re-key, we might start to change CA DNs between generations, like what commercial CAs do.

As I mentioned in my previous mail, we have a national LDAP tree and all entities, including the Government Root CA and all subordinate CAs, have been assigned their unique and permanent DNs. In the future, when our Government PKI starts to change CA DNs between generations, various Root CA nodes and Subordinate CA nodes will be generated in the national LDAP tree and application systems might get confused. This is one issue that we need to solve in the future.

> However, the CA changing its practices could be done on a
> going-forward basis; the existing instances shouldn't be problematic
> and so I don't think they should be excluded on the basis of what they
> already did.

Thanks for this positive opinion. If our root CA will not cause problems to Mozilla NSS/Firefox, I really hope that Mozilla can accept our second generation Government Root CA certificate. Especially, Firefox users in Taiwan have already waited for a long time.

Wen-Cheng Wang

[Wen-Cheng Wang]

On Saturday, December 10, 2016 at 3:30:09 AM UTC+2, Erwann Abalea wrote:
> I don't think there is a bug in IIS here. IIRC, you discovered that IIS doesn't send the self-issued certificate when loaded with the 2 self-signed root certs and the self-issued cert (1st gen signing 2nd gen). And IIS' behaviour is right, in that it doesn't know if the browser will need this link certificate. IIRC again, what was proposed for you is that you declare the 2nd gen self-signed cert as untrusted on your side, to force IIS to send the link.
>

Well, regarding whether it is a bug, I think that depends on whether IIS can distinguish self-issued certificates from self-issued certificates? In our speculation, we guess that IIS treats any certificate of which issuer DN and subject DN are the same as a self-issued certificate. That is why we submit a bug report to Microsoft to explain to them that it might be a self-issued certificate according to RFC 5280 and the X.509 standards. We guess the reason why IIS will not send back our self-issued intermediate certificate to the client is that it treat it as a self-signed root certificate (Note that in SSL/TLS protocol, the server side does not need to send back self-signed root certificates to the client side.) However, if IIS development team does know the different between a self-issued certificate and a self-signed certificate, and they decide not to support self-issued certificates for some reason. Well, you can say that it is not a bug and it is by design.

> Talking about your duties when playing with such renewals, you already know that the population under GCA 1st gen and GCA 2nd gen is the same with regard to generated serial numbers and CRLs produced (the content of the CRL chaining to GCA 1st gen MUST be identical to the content of the CRL chaining to GCA 2nd gen, unless you implement CRL partitioning).
>

In our National LDAP Tree, GRCA and GCA are both permanent entities. After they performing re-key, they are still the same entities in the National LDAP Tree but with different generations of keys. The same situations also apply to re-keys of end-entities. When end-entities' key expired, they will simply generate new keys and apply for new certificate with the same DNs. Please be understood that we have a National LDAP Tree and we intend to keep all entities' DNs permanent, unless they really change their names of jurisdictions.

> And the situation gets weirder with the Root. In X.509, GDCA 1st gen and GDCA 2nd gen are a single CA (serial numbers assigned to issued certs, CRLs, etc). And there's a difference here between RFC5280 and X.509. In RFC5280, the CRL chaining to GDCA 1st gen can't give a valid revocation result for a certificate chaining to GDCA 2nd gen, and thus the set of serial numbers for certs issued by each gen of GDCA may or may not be disjoint. It's an unclear area of RFC5280, and it's not fun to sit in here.
>
> >From what I see, you're doing it correctly from an X.509 point of view. Each GCA gen produces its partitioned CRL plus an unpartitioned complete one, both complete ones are identical in content (except a few seconds delta in the thisUpdate field, unimportant). And I found 3 CRLs issued under GDCA, with identical contents. That should also work if RFC5280 rules are followed.
>

You are right, RFC 5280 is unclear about the relationship between two generations of CRLs. In this matter, we indeed follow what the original X.509 standards says. That is each CA should still issue the Complete CRL even if they issue partitioned CRL.

> Mozilla::pkix doesn't know about self-issued certificates. The library just considers such a certificate as a subordinate CA cert. It happens to work in your specific situation.
>
> > Other https server such aa Apache have no problem with certificate chains containing self-issued certificates.
>
> That may not be true in recent versions, depending on how you configure your server. But again, off-topic.

Yes, actually I think those browsers and https server doesn't know about self-issued certificates, they simply treat them as intermediate CA certificates. However, you know, the original idea of using self-issued certificates to facilitate key-rollover is actually want certificate-using systems treat them like intermediate CA certificates.

Wen-Cheng Wang

[Kathleen Wilson]

Thanks to all of you who have reviewed and commented on this request from Government of Taiwan, Government Root Certification Authority (GRCA), to include their renewed Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits.

To summarize this discussion so far, two primary concerns have been raised, as follows.

1) There are several intermediate certificates that are technically capable of issuing TLS certificates, but have not been audited according to the BRs. This is a show-stopper.

Reference:
https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs
“BR Audits must always include the whole-population audit of intermediate certificates that are capable of issuing SSL certs.”

This means that if the intermediate certificate is not technically constrained via EKU (and name constraints) then it must be audited according to the BRs.

We have resolved this particular situation in the past by having the CA get an audit statement saying that the intermediate certificate has not issued TLS certificates during the audit period. And requiring that the CA get such an audit statement annually.


2) The new root certificate has the same exact full distinguished name as the old root certificate. I think this is OK.

The CA tested this with Firefox, and provided their test results:
https://bugzilla.mozilla.org/attachment.cgi?id=8818360

Question: Do I need to update https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys ?


Please let me know if there is anything else (other than item #1) that this CA needs to address before we may move forward with this request.

Thanks,
Kathleen

[Erwann Abalea]

Bonsoir,

Le mardi 13 décembre 2016 23:36:15 UTC+1, Kathleen Wilson a écrit :
[...]

> Question: Do I need to update https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys ?

There could be something trying to enforce that root certificates sharing the same distinguished name MUST be owned by the same entity (well, the private key, and all the accompanying things). That should also be true for subordinate CAs (wrt cross-signing), but this has to be enforced by issuing CAs.

[Brian Smith]

On Tue, Dec 13, 2016 at 12:36 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> Question: Do I need to update https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys ?

That description seems to have been written to describe the behavior
of the old, non-libpkix, NSS verification code. NSS's libpkix probably
works differently than that. Also, that description is not accurate
and is somewhat misleading for mozilla::pkix.

[Kathleen Wilson]

In regards to updating https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys ?

How about the following?
~~
The standards allow for two CA certificates to have the same subject names but different subject public keys. Please try to avoid this, because it often leads to confusion and compatibility issues. When verifying an end-entity certificate chaining up to a root certificate with the same subject name as another root certificate, if Firefox is aware of the existence of both root certificates, it will try all possible orderings of (subject, issuer) pairs until it finds the right one. If there are many certificates all with the same subject and issuer names, the number of orderings grows exponentially, so it can take a long time to evaluate the certificate chains. Therefore, it is better to avoid these kinds of situations.

Note that for root certificates, Firefox ignores the authority key identifier and subject key identifier extensions.
~~

RE:

> There could be something trying to enforce that root certificates sharing the same distinguished name MUST be owned by the same entity (well, the private key, and all the accompanying things). That should also be true for subordinate CAs (wrt cross-signing), but this has to be enforced by issuing CAs.

Maybe that should be part of the BRs?

Thanks,
Kathleen

[Brian Smith]

Kathleen Wilson <kwi...@mozilla.com> wrote:
> How about the following?

That sounds right to me.

It is important to fix the DoS issue with the path building when there
are many choices for the same subject. SKI/AKI matching only fixes the
DoS issue for benign cases, not malicious cases. Therefore some way of
limiting the resource usage without relying on AKI/SKI matching is
needed.

I'm not sure how to incorporate the possibility of the issue being
fixed into your text.

Cheers,
Brian

[Kathleen Wilson]

On Thursday, December 15, 2016 at 10:56:52 AM UTC-8, Brian Smith wrote:
> It is important to fix the DoS issue with the path building when there
> are many choices for the same subject. SKI/AKI matching only fixes the
> DoS issue for benign cases, not malicious cases. Therefore some way of
> limiting the resource usage without relying on AKI/SKI matching is
> needed.

Indeed, and as per your comment here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24

[Kathleen Wilson]

On Tuesday, December 13, 2016 at 2:36:15 PM UTC-8, Kathleen Wilson wrote:
> Thanks to all of you who have reviewed and commented on this request from Government of Taiwan, Government Root Certification Authority (GRCA), to include their renewed Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits.
>
> To summarize this discussion so far, two primary concerns have been raised, as follows.
>
> 1) There are several intermediate certificates that are technically capable of issuing TLS certificates, but have not been audited according to the BRs. This is a show-stopper.
>
> Reference:
> https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs
> “BR Audits must always include the whole-population audit of intermediate certificates that are capable of issuing SSL certs.”
>
> This means that if the intermediate certificate is not technically constrained via EKU (and name constraints) then it must be audited according to the BRs.
>
> We have resolved this particular situation in the past by having the CA get an audit statement saying that the intermediate certificate has not issued TLS certificates during the audit period. And requiring that the CA get such an audit statement annually.
>

The CA has been working with their auditor to get an appropriate audit statement that covers all of the intermediate certs chaining up to this root.

>
> 2) The new root certificate has the same exact full distinguished name as the old root certificate. I think this is OK.
>
> The CA tested this with Firefox, and provided their test results:
> https://bugzilla.mozilla.org/attachment.cgi?id=8818360
>

The new root cert having the same DN as the old root cert appears to work
from a technical standpoint (i.e. mozilla::pkix will find the right path if all necessary certificates are present). However, the duplicate names have already caused unnecessary confusion:
https://bugzilla.mozilla.org/show_bug.cgi?id=1304264

This "new" root certificate was created in 2012, is included in Microsoft's program, and has several active intermediate certs. So it might not be reasonable to ask the CA to generate a new root certificate at this point in time. However, I urge the CA to take note, and not repeat this with the next generation of their root certificate.

Kathleen

[Peter Gutmann]

Kathleen Wilson <kwi...@mozilla.com> writes:

>Indeed, and as per your comment here:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24

So just to satisfy my curiosity, it's been known ever since top-down
construction was first advocated by PKI loon^H^H^Htheoreticians:

https://www.youtube.com/watch?v=CoOrmK4OueY

that you work bottom-up, not top-down. If that's not obvious just from about
a beer's worth of analysis then it should have been when one of said PKI
theoreticians described trying to implement it at a conference and pointed out
that his implementation ran for three days without terminating, after which he
tried the same thing again.

Did no-one see that this was going to happen? Why would anyone try and do it
this way? Rather baffled minds want to know...

Peter.

[hor...@gmail.com]

Kathleen Wilson於 2017年2月3日星期五 UTC+8上午6時36分54秒寫道：

> On Tuesday, December 13, 2016 at 2:36:15 PM UTC-8, Kathleen Wilson wrote:
> > Thanks to all of you who have reviewed and commented on this request from Government of Taiwan, Government Root Certification Authority (GRCA), to include their renewed Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits.
> >
> > To summarize this discussion so far, two primary concerns have been raised, as follows.
> >
> > 1) There are several intermediate certificates that are technically capable of issuing TLS certificates, but have not been audited according to the BRs. This is a show-stopper.
> >
> > Reference:
> > https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs
> > “BR Audits must always include the whole-population audit of intermediate certificates that are capable of issuing SSL certs.”
> >
> > This means that if the intermediate certificate is not technically constrained via EKU (and name constraints) then it must be audited according to the BRs.
> >
> > We have resolved this particular situation in the past by having the CA get an audit statement saying that the intermediate certificate has not issued TLS certificates during the audit period. And requiring that the CA get such an audit statement annually.
> >
>
> The CA has been working with their auditor to get an appropriate audit statement that covers all of the intermediate certs chaining up to this root.
>

In accordance with Kathleen's advice, our auditor has provided such a audit statement.(https://bug1065896.bmoattachments.org/attachment.cgi?id=8835815)

[Peter Gutmann]

I wrote:

>Did no-one see that this was going to happen? Why would anyone try and do it
>this way? Rather baffled minds want to know...

Is no-one at Mozilla able to explain why they did this? It's a nontrivial
piece of code to implement, surely someone must know what the thinking was
behind doing it this way?

Peter.

[Gervase Markham]

On 11/02/17 12:13, Peter Gutmann wrote:
> Is no-one at Mozilla able to explain why they did this? It's a nontrivial
> piece of code to implement, surely someone must know what the thinking was
> behind doing it this way?

Peter: you are going to have to re-summarise your question. And then, if
you are asking why Mozilla code works in a certain way,
mozilla.dev.security or mozilla.dev.tech.crypto are almost certainly far
better venues.

Gerv

[Peter Gutmann]

Gervase Markham via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Peter: you are going to have to re-summarise your question. And then, if you
>are asking why Mozilla code works in a certain way, mozilla.dev.security or
>mozilla.dev.tech.crypto are almost certainly far better venues.

Sure, no problem. I was just replying to a post by Kathleen on this list, and
it seemed like a policy issue so I figured it was the right forum. I'll CC it
to dev.security as well...

The original post was about the fact the Mozilla runs into lots of problems
with top-down path construction:

>Indeed, and as per your comment here:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24

I asked:

So just to satisfy my curiosity, it's been known ever since top-down
construction was first advocated by PKI loon^H^H^Htheoreticians:

https://www.youtube.com/watch?v=CoOrmK4OueY

that you work bottom-up, not top-down. If that's not obvious just from about
a beer's worth of analysis then it should have been when one of said PKI
theoreticians described trying to implement it at a conference and pointed out
that his implementation ran for three days without terminating, after which he
tried the same thing again.

Did no-one see that this was going to happen? Why would anyone try and do it

this way? Rather baffled minds want to know...

Peter.

[Kathleen Wilson]

All,

My apologies for taking so long to get back to this discussion about the Government of Taiwan's (GRCA's) request to include their Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits.

Note that GRCA has suggested that this root be constrained to *.tw.

To my knowledge, the questions and concerns raised about this request have been resolved. In particular:

1) There are several intermediate certificates that are technically capable of issuing TLS certificates, but have not been audited according to the BRs. We have resolved this particular situation in the past by having the CA get an audit statement saying that the intermediate certificate has not issued TLS certificates during the audit period. And requiring that the CA get such an audit statement annually.

GRCA has provided the requested audit statement:
https://www.google.com/url?q=https%3A%2F%2Fbug1065896.bmoattachments.org%2Fattachment.cgi%3Fid%3D8835815&sa=D&sntz=1&usg=AFQjCNH9syh0sbLxMj35bdC1TDeQslx32w

2) The new root certificate has the same exact full distinguished name as the old root certificate.

My recommendation is that we allow it this time, but not for future root certs from this CA.

So, if there are no further questions or comments about this CA's request, then I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen

[Kathleen Wilson]

On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote:
>
> So, if there are no further questions or comments about this CA's request, then I will close this discussion and recommend approval in the bug.
>

All,

I requested that this CA perform a BR Self Assessment, and they have attached their completed BR Self Assessment to the bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30

Aaron has reviewed and verified the BR Self Assessment.

Therefore, I plan to approve this request from the Government of Taiwan (GRCA) to include their "Government Root Certification Authority" root certificate, and turn on the Websites and Email trust bits, and constrain this root to *.tw.

If there are no further concerns, then I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen

[Kathleen Wilson]

After further consideration, I have decided to wait for the CA to provide their updated CP/CPS that will address all of the shortcomings that they noted in their BR Self Assessment that they plan to fix in the next version of their CP/CPS.

So, this discussion will be on hold again until I have received and reviewed their updated CP/CPS documents.

Thanks,
Kathleen

[wth...@mozilla.com]

We have received the updated CP/CPS and have received and verified the most recent audits for this CA. Since we haven't yet implemented the changes to our inclusion process proposed by Kathleen a few days ago, I am now restarting discussion on this request, and I will post my comments once the CP/CPS review is completed.

I plan to recommend that the XCA, MOICA, and MOEACA sub-CAs be added to OneCRL because they are neither technically constrained or BR audited.

Wayne

[wth...@mozilla.com]

This root inclusion request is currently in the public discussion phase [1]

After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the following comments:

==Good==
1. GRCA has requested that this root be constrained to issuing certificates for .tw domains.
2. The BR Self Assessment is very detailed and helpful.

==Meh==
1. This root is intended to replace an older root that has the exact same DN. Compatibility concerns were raised but testing performed by GRCA found no problems.
2. The CP doesn’t contain the ’dated changelog’ required under Mozilla policy section 3.3.
3. The audit reports don’t include the version numbers of CA policy documents referenced during the audit.
4. The WebTrust for CAs audit report doesn’t list all the subordinate CAs covered by the audit. They are listed in a supplemental statement provided by the auditor.
5. The CP/CPS docs are still in RFC 2527 format.
6. It is not clear how the policy for authenticating individual identity described in section 3.1.9 of the GCA CPS meets the requirements of BR 3.2.3 and 3.2.5. Please provide more detail.
7. In September it was reported that GRCA was signing OCSP responses with an unconstrained SHA-1 certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 The issue has been fixed.
8. Procedures that fulfill Mozilla policy section 2.2(2) requirements for validating email addresses are not specified in any documents.

==Bad==
1. The application for inclusion states that only the GCA subordinate can issue SSL certificates, and this subordinate has its own CPS that lists SSL-specific policies such as CAA. The HCA subordinate also has a BR audit, but GRCA has stated that it is no longer used to issue SSL certificates. Should the HCA subordinate be added to OneCRL along with the other subordinates (XCA, MOICA, and MOECACA) that are not BR audited?
2. According to the audit supplement, the MOICA audit report is qualified due to ‘one issue related to system access management’, but the actual audit report is not written in English. Please describe the issue and how it was resolved.
3. The GCA CPS describes CAA policies, but GRCA’s issuer domain names are not listed as required by BR section 2.2.
4. GCA CPS section 3.1.12 describes the domain authorization process for SSL certificates, but it does not comply with Mozilla policy section 2.2(3).

One of the recent updates to the application process [1] is a 3-week time period for public comments. I would like to apply that change to this inclusion request. Specifically, if GRCA has sufficiently answered the questions that I have raised above, and any other discussion on this list has reached a conclusion, then I will plan to close the discussion period on 10-Feb.

- Wayne

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1065896

[Ryan Sleevi]

On Fri, Jan 12, 2018 at 2:27 PM, Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> We have received the updated CP/CPS and have received and verified the
> most recent audits for this CA. Since we haven't yet implemented the
> changes to our inclusion process proposed by Kathleen a few days ago, I am
> now restarting discussion on this request, and I will post my comments once
> the CP/CPS review is completed.
>
> I plan to recommend that the XCA, MOICA, and MOEACA sub-CAs be added to
> OneCRL because they are neither technically constrained or BR audited.
>

Has any consideration been given to adopt a similar policy as discussed
with the Government of Korea application -
https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38

[Dimitris Zacharopoulos]

On 26/1/2018 11:54 μμ, Ryan Sleevi via dev-security-policy wrote:
> Has any consideration been given to adopt a similar policy as discussed
> with the Government of Korea application -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38

Just to avoid any possible mis-reading of:

"If you have intermediates for which you cannot disclose, whether it be for personal, operational, or legal reasons, then an appropriate solution, consistent with Mozilla CA Certificate Policy, is to use Technically Constrained Subordinate CAs - as defined within the Baseline Requirements and as reflected within the Mozilla policy. Such TCSCAs are technically limited from the issuance of TLS certificates, and by doing so, are allowed to be operated in a way that is not consistent with the Baseline Requirements nor compliant with Mozilla Policy."


Currently, the Baseline Requirements (section 7.1.5) allow for TCSCAs to
issue TLS Certificates, by requiring the nameConstraints extension,
limiting the issuance to specific Domain Names and Organizations. These
TCSCAs MUST follow the Baseline Requirements, with the exceptions
provided for these types of TCSCAs.

As far as the Mozilla Policy is concerned, if a TCSCAs is technically
capable of issuing a Certificate for TLS authentication or S/MIME, it
MUST comply with the Mozilla policy, with the exceptions provided for
TCSCAs. Section 1.1 of the Mozilla Policy is fairly clear on the scope
of the policy. If there are possibly more exceptions, it should probably
be updated to reflect these cases.


Dimitris.

[Wayne Thayer]

Thanks for pointing this out Ryan and Dimitris. You are both correct: we
should direct Taiwan GRCA to change their request from including the root
to including only the subordinate CAs that comply with the Mozilla policy.
The option of adding the non-compliant subordinate CAs to OneCRL does not
meet our policy.

I will determine what additional information we need to change this
inclusion request and will add it to bug 1065896. I then expect to place
this request on hold until we receive the updated information.
<https://bugzilla.mozilla.org/show_bug.cgi?id=1065896>

- Wayne

On Sun, Jan 28, 2018 at 10:53 PM, Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

>
>
> On 26/1/2018 11:54 μμ, Ryan Sleevi via dev-security-policy wrote:
>
> Has any consideration been given to adopt a similar policy as discussed

> with the Government of Korea application -https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c38