On 03/12/2016 09:34, lcchen.ci...@gmail.com wrote:
Kathleen Wilson於 2016年11月15日星期二 UTC+8上午9時20分09秒寫道：
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
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.”]
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
