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. > 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. > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
