For what it's worth, I think that there should be two distinct cases:
a) Self-signed Certificates that have the same SPKI and name, but only
one was ever requested to be included as a Trust Anchor in the Mozilla
Root Program,
b) Variations of Issuing CA Certificates that have the same SPKI and name.
For b), the rules of disclosure in the Mozilla Policy were very clear
and unambiguous. I would expect all versions of b) to be included in
audit reports.
For a), in my understanding, if the CA only requested one version of the
Root CA Certificate to be included, the possible other versions could
"theoretically" be considered "Intermediate" CA Certificates but they
are self-signed and effectively do not transfer any trust over, unless I
am missing something. So, when the disclosure requirement was drafted in
the policy, I don't think it was ever intended for CAs to disclose all
variations of their Root CA Certificates that share the same SPKI and
name. Wayne and Kathleen, as module owners, could confirm if this is
true or not. If CAs were intended to add all variations of their
self-signed Root CAs, it would have been highlighted and discussed on
this list as a corner case (I can't remember if this corner case was
discussed when writing the disclosure policy). And even if CAs wanted to
disclose these in CCADB, it was counter-intuitive to add a self-signed
Root as an Intermediate.
It is possible that a CA issued two or more variations of their Root CA
Certificate, changing extensions and other information if they detected
that something was incorrect. IMHO that should not effect anything
because at the end of the day, the Trust Anchor is the one that matters.
I also can't think of a "bad actor" case for a) that could take
advantage of this theoretical "gap" to cause any security risks, but
perhaps others could. With that said, I believe there should be some
guidance on the wiki of CCADB or Mozilla Policy that describe this
corner case and have a process for adding "variations" of such
self-signed certificates as "Intermediate CA" Certificates (when most
people are used to see them as self-signed "Root CA" Certificates). As
long as the SPKI and name is included in consecutive audit reports from
the creation of one of those variations, there should be a grace period
allowing the other variations to be disclosed and be included in future
audit reports. It would be causing "pain" to CAs and auditors to update
existing audit reports to retroactively disclose such cases, for no good
reason.
I am not sure if adding one of the self-signed Root CA variations in the
OneCRL (not the one included as a Trust Anchor) would cause any harm to
the properly disclosed and audited hierarchy. Could someone please
clarify that?
Finally, I don't think auditor professional ethics have anything to do
with this discussion. Both audit schemes allow for reports to be updated
otherwise we wouldn't even have this option on the table. Challenging
audit schemes is good and healthy but should probably be on a separate
thread with specific concerns raised.
Thank you,
Dimitris.
On 2020-02-07 6:00 μ.μ., Wayne Thayer via dev-security-policy wrote:
On Thu, Feb 6, 2020 at 5:44 PM Ryan Sleevi via dev-security-policy <
[email protected]> wrote:
<snip>
My recommendation is that, for audit periods ending within the next 30 or
so days (meaning, effectively, for reports provided over the next 4 months,
given the three month window before reporting), such situations are
accepted despite the limited assurance they provide. Following that - that
is, for any audit afterwards, there is zero exception, and revocation is
required.
I'd like to see Mozilla require an incident report from CAs that can't or
won't follow the existing guidance (by either supplying a revised audit
statement, revoking the certificate, or adding it to OneCRL). A number of
CAs have resolved these issues by following this guidance and I recommend
against adding a grace period at this time for those who have not.
This places the onus on the CA to ensure their audit reports will meet
Mozilla’s requirements.
In the future, I expect ALV to catch these issues as soon as the audit
report is published. Mistakes do happen, and I don't think our policy
should go straight to revocation upon an ALV failure due to an audit
statement error.
2) Should we accept a revised audit statement to include the SHA256
fingerprint of a certificate that was not previously listed and does not
have the same Subject + SPKI as other cert(s) listed in the audit
statement?
<snip>
I realize Mozilla uses OneCRL to address the gap there, but ostensibly this
is a straight BR violation regarding providing continuous audits. The
proposed revisions will make this unambiguously clearer, but either way,
the best path to protect the most users is to require the CA to revoke such
certificates.
This also hopefully has the desired effect of forcing CAs to pay closer
attention to the requirements placed on them, and ensure that the negotiate
and scope their audits to ensure they’re actually meeting those
requirements.
I agree, but I also think that ALV will cause these issues to be caught and
quickly corrected in the future (assuming the CA has properly disclosed all
CA certificates).
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
