On Sat, Dec 3, 2016 at 9:22 AM, Jakob Bohm <jb-mozi...@wisemo.com> wrote: > On 03/12/2016 09:34, lcchen.ci...@gmail.com wrote: >> >> 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. > > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
