(In reply to Jeremy Rowley from comment #3)
I greatly appreciate you raising this because the items you asking for point out a gap in the Mozilla policy. We are, of course, willing and happy to go through each ICA disclosure and ensure the records are accurate. However, before we do so, we’d like to see an official Mozilla policy clarification about how to mark/disclose new ICAs as this is the ultimate source of confusion on this report.
The original ICAs listed were all disclosed in CCADB, but the audits were not marked “Same as Parent”. Although the ICAs were operated in DigiCert’s infrastructure, the ICAs were not audited yet, although they will be covered in the next audit. You pointed me to this discussion: (https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/CAaC2a2HMiQ/IKimeW4NBgAJ). However, this discussion does not detail exactly what you should do with CCADB between when the ICA is created and when the audit happens.
I'll admit, I'm not terribly happy with this response. It seems a return to Symantec's process of rules lawyering. I'm all for clarification, but I think if a CA is going to argue that there's confusion, they should have raised this.
For example, a CA that had been following m.d.s.p. and the CA/Browser Forum would, for example, know that this very topic was touched on during last year's 2.6 update, in the context of Policy Issue #32. You might see, for example, that at the linked thread you mentioned, that Wayne's original posting stated
the TSP can select "CP/CPS same as parent" and "Audits same as parent" in CCADB to indicate that the same policies apply to the new subordinate as to the root.
I'm not sure where the perceived gap is, given that it was specifically addressed in the message you mentioned.
The help text for the "Same as Parent" checkbox in CCDAB says "Click this box if audit of parent cert includes this cert". This is clearly incorrect as the audit of the parent cert does not include this cert. By default we usually check this box. However, we have an employee who is worried that doing so provides mis-leading information since new ICAs are clearly not audited the same as parent until the next audit cycle. I think they are correct.
As part of your incident response, it would be useful to know why this issue wasn't raised or addressed previously.
The policy says the CA must disclose the ICA on the next periodic audit report, not the current audit report. Uploading the ICA and checking the box the way Google does it (marking it the same as parent, for example GTS Y1 issued 11/1/2018 claiming same as parent: https://ccadb.force.com/0011J00001K3m7X?srPos=0&srKp=001) is potentially misleading and misrepresenting when the audit occurs.
Could you explain, perhaps, what you believe an audit covers? I am deeply troubled by the suggestion that audits apply to specific certificates, and I'm quite concerned if CAs are confused by that. An audit is an assessment of an organization's ability to execute according to a stated set of procedures (a CP/CPS), based on evidence observed. The scope of that evidence would consider existing keys, and their associated certificates.
For example, it would be absolutely laughable if a CA were to argue it was perfectly OK use their CA key to sign a misissued certificate, setting the same issuer name and key of their 'in-scope' certificate, but then to claim it wasn't misissuance because what 'actually' signed it was some 'out-of-scope' version. While that seems extreme, that's logically what you're claiming here, especially as demonstrated below, so you can understand why I am quite concerned.
Therefore, I think the Mozilla policy needs to be updated to clarify the following:
- Should the audit box be checked for same as parent before the audit happens?
This was previously addressed.
- If so, should there be a note to indicate that the audit has not yet happened?
As for the Apple ICAs, this isn’t a quality issue. The difference between the audit listings is the limitations in CCADB issue and a lack of Mozilla policy on what you do with audit same as parent in the gap between when the ICA is created and when the new audit is conducted. This is the very same issue that caused the original but to flag the ICAs as non-disclosed. We’re happy to fix the listings if we can get clarity around how the ICAs should be properly listed in the interim period between the creation and audit.
I'm sorry, but I find this answer unacceptable. The reason is because you signed the exact same issuer name and key. As mentioned above, what you're functionally claiming is that this certificate is somehow 'out of scope' of the CA's audit, even though all certificates previously issued verify just as well to the newly issued certificate, and conversely, all certificates issued by the 'new' certificate are just as valid under the old. I specifically picked these certificates, because they demonstrate this case of an extant key pair and subject name.
Taking the Apple ICAs as an example, our option was to:
- Use the previous Apple audit. However, the previous audit report doesn’t specify this ICA. We felt this was the most devious option since the ICA was clearly not listed in the previous Apple audit.
- Put nothing, but that gets the CA flagged by the needs audit report and means the ICA (per this bug) was not actually disclosed in the 7-day requirement.
- Flag the ICA as same as parent. We listed the ICA this way to indicate it would be listed in the next audit.
CCADB does not give an option to indicate this information correctly. We chose option 3. Option 1 could have been a better option, but none of them accurately represent the real situation.
Are you suggesting that you deliberated all of these decisions and choose the path you did? And that your Compliance team reviewed these and agreed that the best course of action was not to raise a question or concern, despite your perceived ambiguity, and instead do what you think was best? And even though this very topic had been previously been discussed?
I want to be clear, there's only one other time I'm aware of where such a claim has been made, and that was in the root inclusion of new DarkMatter roots, and such a response was very unfavorably received. If there is confusion or ambiguity, it should be raised.
Here's what I'm most concerned about: The choices in disclosure that DigiCert has made actively mislead the community about the entities in possession of private keys capable of TLS issuance. The improper disclosures, as such, cause real and demonstrable harm, in that they fail to distinguish independent organizations. I was shocked to see it for Apple, because I knew Apple was in possession of their private key - because it's listed right their in their audit. And there is absolutely no way that the key is in DigiCert's facilities. Whatever perceived ambiguity may exist, that choice was quite literally the worst choice and most misleading and harm-inducing.
Beyond that, I'm concerned because these were trivially detectable at https://crt.sh/mozilla-disclosures . You can still see that as of 2019-07-09, three of those sub-CAs are still not resolved, one of them which has been on that list since 2019-04-30, the other two since 2019-06-25, and all three mentioned in Comment #0. Given that DigiCert has already had issues where certificates were listed on that dashboard for some time, and Mozilla had to chase down Digicert management, I'm concerned that nothing in the intervening year was taken away to improve that process, and I'm worried that the takeaway now may be to mislead the public, as was done with Apple, in order to squelch such warnings. While ALV for intermediates in CCADB would detect such obvious misstatements, I'm worried that at any point it was seen as acceptable as stating Apple's "new" intermediate - which instantly made trusted (to the Baltimore root) every past certificate ever issued by their "old" one - was somehow seen as the best option. It really doesn't make any sense, and thus, I'm worried for all disclosures.