Frank Hecker wrote: > Nelson B Bolyard wrote: >> Frank Hecker wrote: >>> For the record, I am pretty sure that we have CAs already in the >>> root list that have issued test certs under their hierarchies. >>> IIRC the last instance of this I saw was a CA that had a >>> subordinate CA used to testing purposes, under the root CA that >>> we include. > <snip> >> Please elaborate. What CA did that? >> Is the subordinate CA that did so still valid (unexpired)? > > I have no idea. This is just a vague remembrance on my part, and I > can't vouch for its accuracy. > >> IMO, this is a serious enough breach that it warrants calling for the >> removal of the CA that did it. If the subordinate CA is still valid >> and is not revoked, this calls for drastic action. > > Let's ignore for a moment the question of whether a CA did this or > not (because as I noted above, my recollection may be faulty). I'm > still unclear on why issuing issuing one or more test certs from a > CA hierarchy is in and of itself a problem, *irrespective of the > circumstances under which they were issued*. I'm not referring to > issuing test certs to people outside the CA, in a way that bypasses > normal controls; that's clearly out of bounds.
And, That's the scenario of concern, the one that's "out of bounds". > I'm talking about internal testing by the CA's operations staff. As long as there are sufficient controls on such internal CA testing, that's fine. > If I'm running a CA, and I want to test my procedures for issuing > certs, then what's the problem with having my internal staff issue > a test cert under a given hierarchy, in order to verify technical > details, compatibility with applications, etc., and then destroying > the private key for the cert to ensure it can't be further used? > You're telling me that no one at a CA has ever done this, and should > never do it? No, I'm not talking about controlled CA testing. The case of which I had previously heard was of a corporate CA that was subordinate to a public root CA that was trusted in Mozilla, but expired a few years ago. The corporate CA issued two subordinate CA certs to subordinate internal corporate CAs. One of those internal CAs was intended to issue official SSL server certs for use by official company internal SSL servers, and applications for certs from that CA were verified for authenticity and required management approval for issuance (or so I was told). The other of those two internal subordinate CAs was a "Test CA". It was available to all company employees and no authentication whatsoever of any information in the cert was performed. Employees could instantly get SSL server certs for any DNS name of their choosing within the company's own domains and subdomains. Certs from the test CA locked the browser's lock icon just as well as certs from the official CA, in nearly any browser on earth, and had normal validity periods, so they didn't expire soon after issuance. (The description given of TurkTrust's test CA reminded me of that, except that I'm not sure TurkTrust's test CA limits the DNS domain in which the cert can be issued.) The certs from this "test CA" contained a string in the subject name that disclaimed that the subject name was unverified (or some similar disclaimer), and the people who ran the test CA naively thought that was sufficient to prevent the test CA certs from being abused. But of course, no browser user ever looks at the actual SSL server certs unless the server cert fails to validate and causes a browser warning. If the browser shows the lock, then browser users are satisfied that the CA has done its job of authenticating the cert's subject. (TurkTrust's repeated insistence that its test certs are not recognized as valid under Turkish law reminded me of that, as if users are capable of distinguishing valid-but-not-legally-recognized certs from valid and legally recognized ones.) I suspect you can guess what happened. Fortunately, the root CA cert itself expired soon thereafter, and all the certs subordinate to that root are no longer valid. But if this ever happens again, we need to take swift action against any CA that allows that to happen, IMO. Regarding TurkTrust, if (as they say) the test certs come from a CA that chains up a separate, untrusted root, then all is well. But perhaps you could ask for a test cert and its chain, just to make sure it doesn't chain up to a to-be-trusted root? _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
