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