When should CAs notify Mozilla of intermediate cert revocations?

[Kathleen Wilson]

All,

Let’s start the policy discussion about preloading revocations of
intermediate CA certificates.

https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates

In particular, I’d like to discussion *when* a CA should notify Mozilla
of a revocation of an intermediate certificate, so that certificate can
be included in the revocation list push mechanism.

On the wiki page I’ve listed the following as a starting point.
Does this list make sense?
Is there anything missing?
Would it be OK to directly reference the NIST IR 7924 document?
(http://csrc.nist.gov/publications/drafts/nistir-7924/draft_nistir_7924.pdf)
Or should Mozilla policy list the specific cases anyways?

--
When To Notify Mozilla:
* Technical Issue - There is a problem with the intermediate certificate
such that the certificate may be inappropriately used. This includes,
but is not limited to, wrong key usage, incorrect name constraints, etc.
* An externally-operated subordinate CA certificate has been revoked or
replaced (for any reason) before it has expired.
* Cessation of business operation. (Is this one covered by the previous
bullet point?)
* According to NIST IR 7924 a Trust Anchor Manager (TAM) is an Authority
who manages a repository of trusted Root CA Certificates. As specified
in Section 5.7, the TAM will require the CA to provide notification when:
** Root CA compromise -- Compromise of CA private signing key
(Notification shall be made in an authenticated and trusted manner...
earliest feasible time and shall not exceed <24> hours beyond
determination of compromise or loss unless otherwise required by law
enforcement)
** Intermediate or Subordinate CA key compromise (revocation information
shall be published immediately in the most expedient, authenticated, and
trusted manner but within <18> hours)
** Compromise of Certificate Status Server (CSS) key, an example of a
CSS is an OCSP server. (If the CSS is self-signed and the CSS
certificate expiration is more than <7> days away, the vendor shall
immediately notify the trust anchor managers)
** RA key compromised (the revocation information shall be published
within <24> hours in the most expedient, authenticated, and trusted manner)
** Suspected or detected compromise of any CA system or subsystem
** Physical or electronic penetration of any CA system or subsystem
** Successful denial of service attacks on any CA system or subsystem
** When computing resources, software, and/or data are corrupted
** Any incident preventing a CA from issuing and publishing a CRL or
OCSP prior to the time indicated in the nextUpdate field in the
currently published CRL or OCSP suspected or detected compromise of a
certificate status server (CSS) if
*** the CSS certificate has a lifetime of more than <72> hours; and
*** the CSS certificate cannot be revoked (e.g., an OCSP responder
certificate with the id-pkix-ocsp-nocheck extension)
--

I will greatly appreciate your thoughtful and constructive input into
this discussion.

Kathleen

[Gervase Markham]

On 05/09/13 19:02, Kathleen Wilson wrote:
> In particular, I’d like to discussion *when* a CA should notify Mozilla
> of a revocation of an intermediate certificate, so that certificate can
> be included in the revocation list push mechanism.

Those two circumstances do not have to be the same. That is, 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.

It seems to me that this is actually the right strategy. CAs should use
few enough intermediates that informing us about all of them, at least
privately, would not be a problem - particularly if we have an automated
system they can tie into.

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.

Gerv

[Jeremy Rowley]

By "CAs should use few enough intermediates that informing us about all of them, at least privately, would not be a problem - particularly if we have an automated system they can tie into," do you mean that CAs should have few enough revoked intermediates? 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.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Gervase Markham
Sent: Tuesday, September 10, 2013 4:59 AM
To: Kathleen Wilson; mozilla-dev-s...@lists.mozilla.org
Subject: Re: When should CAs notify Mozilla of intermediate cert revocations?

On 05/09/13 19:02, Kathleen Wilson wrote:

> In particular, I’d like to discussion *when* a CA should notify
> Mozilla of a revocation of an intermediate certificate, so that
> certificate can be included in the revocation list push mechanism.

Those two circumstances do not have to be the same. That is, 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.

It seems to me that this is actually the right strategy. CAs should use few enough intermediates that informing us about all of them, at least privately, would not be a problem - particularly if we have an automated system they can tie into.

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.

Gerv

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

On 11/09/13 04:50, Jeremy Rowley wrote:
> By "CAs should use few enough intermediates that informing us about
> all of them, at least privately, would not be a problem -
> particularly if we have an automated system they can tie into," do
> you mean that CAs should have few enough revoked intermediates?

I guess I do.

I would be interested in hearing from CAs of various sizes, if they
don't consider it sensitive information, how many intermediate certs
(for the Web PKI) they cut every year, and how many of them end up revoked.

> Will
> Mozilla really want a notice every time a new intermediate is cut?

I guess CT will give us that eventually ;-)

Gerv

[Michael Ströder]

Kathleen Wilson wrote:
> Let’s start the policy discussion about preloading revocations of intermediate
> CA certificates.
>
> https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates
>
> In particular, I’d like to discussion *when* a CA should notify Mozilla of a
> revocation of an intermediate certificate, so that certificate can be included
> in the revocation list push mechanism.

I'd recommend that a CA puts a revoked sub-CA cert immediatley on its CRL.
So no need to inform Mozilla and no need for this insecure extra
process/mechanism at all.

Ah, the Mozilla developers removed CRL support...maybe Mozilla wants to
finally be the one-and-only super CA.

Ciao, Michael.

[Erwann Abalea]

Le vendredi 20 septembre 2013 20:44:23 UTC+2, Michael Ströder a écrit :
> Kathleen Wilson wrote:
> > Let’s start the policy discussion about preloading revocations of intermediate
> > CA certificates.
> >
> > https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates
> >
> > In particular, I’d like to discussion *when* a CA should notify Mozilla of a
> > revocation of an intermediate certificate, so that certificate can be included
> > in the revocation list push mechanism.
>
> I'd recommend that a CA puts a revoked sub-CA cert immediatley on its CRL.
> So no need to inform Mozilla and no need for this insecure extra
> process/mechanism at all.

The issuing CA will still have to revoke the sub-CA certificate, and publish its revoked status (CRL+OCSP).

Some CAs have produced certificates without CRLDP or AIA:OCSP extension, revocation checking can't be performed for such certificates (hard-fail is a possible mitigation, but not a perfect one).

OCSP responder certificates can't be revoked, that was made possible by RFC2560, and made mandatory by CABF BR. Mozilla proposes to use that notification mechanism to solve this.

> Ah, the Mozilla developers removed CRL support...maybe Mozilla wants to
> finally be the one-and-only super CA.

Mozilla is already a super CA. Google, Microsoft, Adobe, Opera, Oracle, etc are all super CAs. Linux distribution vendors are also super CAs, because they too distribute root certificates (additional ones).

[Rick Andrews]

I'd like to explore how "Notification shall be made in an authenticated and trusted manner". Kathleen's wiki page says to send email to secu...@mozilla.org or file a bug. How would Mozilla determine that the request was legitimate?

I suspect that Mozilla already maintains a short list of contacts for each CA. Only they (or some selected subset of them) should be able to report a revocation. Mozilla should have some other means of authenticating them. Maybe you have a cell phone number for each, which you will call to validate the request.

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.

[Brian Smith]

On Wed, Oct 30, 2013 at 5:14 PM, Rick Andrews <r.an...@computer.org> wrote:
> I'd like to explore how "Notification shall be made in an authenticated and trusted manner". Kathleen's wiki page says to send email to secu...@mozilla.org or file a bug. How would Mozilla determine that the request was legitimate?

If you do it in a bugzilla bug report, then you will be authenticated
using your bugzilla credentials.

> I suspect that Mozilla already maintains a short list of contacts for each CA. Only they (or some selected subset of them) should be able to report a revocation. Mozilla should have some other means of authenticating them. Maybe you have a cell phone number for each, which you will call to validate the request.

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. 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.

> 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 do not know if we need a new standard for this right away. We should
investigate whether bugzilla.mozilla.org can serve as an unofficial
clearinghouse for the smaller trusted root operators.
bugzilla.mozilla.org has an API that allows programmatic access for
filing bugs (which would allow CAs to build automation) and
programmatic access for querying for bugs (which would allow the
smaller trusted root operators to extract the information
automatically from bugzilla).

I expect that the number of revocations that need to be reported using
this mechanism would be very, very low. If it is not very low then I'd
like to investigate ways to make it very low. For example, dropping
the CRLDP extension from intermediate certificates might allow CAs to
avoid rotating intermediates so frequently since "too big to fail"
will not be an issue (at least regarding the size of CRLs). Similarly,
shortening the (allowed) validity period of externally-operated
intermediate certificates so the validity period never extends beyond
the length of the fully-paid-up part of the customer's contract with
the CA may greatly reduce the number of intermediate certificates that
get revoked. Improving mis-issuance prevention measures should drive
the number of mis-issuances to zero, ideally.

Improving the TLS protocol to make multi-stapling practical
performance-wise, combined with a must-staple X.509 extension that
applies to intermediates, should also greatly reduce the need for
reporting revocations this way.

With all this in mind, it isn't clear that we'd benefit from having a
interim standard to hold us over until all revocation information can
be stapled into every full handshake in an efficient way. In fact, I
could see such an interim standard being harmful if it distracts
implementers from working towards making multi-stapling work 100% of
the time.

Cheers,
Brian

[Kathleen Wilson]

All,

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.

Agreed.

> 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
too-big-to-fail CRLs.

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
disposed of.

Does the list of "When to Notify Mozilla" cases need to be updated to
address this in the wiki page?
https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates

> The issuing CA will still have to revoke the sub-CA certificate,
> and publish its revoked status (CRL+OCSP).

Correct.

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
Mozilla.

> I suspect that Mozilla already maintains a short list of
> contacts for each CA.

Correct.

> 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.


Thanks,
Kathleen