Thank you to those of you who have participated in this discussion.
Here’s my response to this discussion so far.
> We could require CAs to notify us of intermediate
> certificate revocations even if, at that point in time,
> we were not intending to include them in the
> push mechanism.
> Then, we can change this question to the policy question of:
> "which revocations should we include in our push mechanism",
> and we have the flexibility to change the answer to that
> over time without having to go back to the CAs and get
> them to change their procedures.
Actually, I think it would be a little reversed. I think Mozilla policy
should state when the CA has to notify us of the intermediate
certificate revocation, regardless of if we currently include them in
the push mechanism. The push mechanism may evolve over time, or we may
decide that a revoked intermediate doesn’t need to be included in the
push mechanism because it was never put into a position where it could
be maliciously used.
> Will Mozilla really want a notice every time a new
> intermediate is cut?
> I can see the advantage of doing that for intermediates
> provided to third parties, but I'm not sure it provides
> much advantage if intermediates are housed within
> the CA's own infrastructure. Plus, if a CA is frequently
> rotating intermediates to limit the "too big to fail" issue
> then there could be a significant number of intermediates.
As Brian mentioned, there may be other ways to mitigate the
However, I have also heard that CAs often create short-lived
intermediate certificate for testing purposes, and those cert are never
put into a position in which they could be maliciously used.
Personally, I don't think we want to know about those types of
intermediate certs, so long as they are safely housed and properly
Does the list of "When to Notify Mozilla" cases need to be updated to
address this in the wiki page?
> The issuing CA will still have to revoke the sub-CA certificate,
> and publish its revoked status (CRL+OCSP).
In addition to maintaining CRL and OCSP, we are discussing the policy
that needs to be added to support the revocation push mechanism that
Mozilla will be implementing. There are a lot of revocations that
browsers do not need to know about or include in their revocation push
mechanism. So we want to identify the revocation situations that do need
to be considered.
> From the CA's perspective, I'd like this process to work the
> same for Apple, Microsoft and any other trusted root operator.
> I urge Mozilla to work with these other companies to come up
> with a unified standard.
I understand the desire to have one common place where all CAs could
post their revoked cert information where it would be available to all
relying parties. However, as Brian mentioned, hopefully there is not a
large number of intermediate certificate revocations that CAs need to
notify browsers about. If this becomes an issue, then we will certainly
look into the reasons and remedies.
In the meantime, I think Bugzilla is the best notification mechanism for
> I suspect that Mozilla already maintains a short list of
> contacts for each CA.
> If the reporter attaches the affected certificates, and/or links
> to the OCSP responses (which you can do if your OCSP responder
> supports GET), we can verify the revocation by looking at the OCSP
> responses. This will allow *anybody* to report a revocation to us
> in a way that we can authenticate.
Yes. This is the preferred case.
> If a CA is reporting a revocation that it hasn't
> revoked via OCSP then we can only authenticate the
> request by checking the bugzilla credentials that
> were used to file the report.
If the reporter is not one of the points-of-contact that we have for the
CA, then we would directly ask our points-of-contact about the revocation.