CA:ImprovingRevocation: Difference between revisions

Jump to navigation Jump to search

CA:ImprovingRevocation (view source)

Revision as of 18:34, 1 October 2014

5,145 bytes removed ,  1 October 2014
→‎Preload Revocations of Intermediate CA Certificates
Line 214: Line 214:


* Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.
* Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.
=== Preload Revocations of Intermediate CA Certificates ===
Push revocation information of revoked intermediate CA certificates to clients.
Implement a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker.
We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]
* Code Change: ''Bug Number''
* Dependencies:
** This will require a bootstrapping effort where we ask all CAs to provide us with a comprehensive list previous relevant revocations.
** Will require a notification mechanism for CAs to inform us of which certs to add to the revocation list.
** In the short term, we will (probably) respond to the revocation notification by issuing a browser security update that contains the updated list of revoked certificates. In the long term, we may have a lighter-weight mechanism for updating the browser with updated revocation information, similar to Google's CRLSet mechanism.
* Policy Change: To be discussed and proposed in the mozilla.dev.security.policy forum.
'''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 [http://csrc.nist.gov/publications/drafts/nistir-7924/draft_nistir_7924.pdf 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)
'''Time Frame''' for Notification: within 24 hours of revocation of an intermediate certificate
'''How to''' notify Mozilla of a revocation
* If the revocation is due to a security concern or of revocation of a website certificate whose revocation was not prompted by the certificate owner, send email to security@mozilla.org.
* To notify us of an intermediate certificate revocation, submit a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. Whenever possible, the CA should send us the revoked certificate itself, along with the rfc5280 revocation reason code. If the CA cannot send us the revoked  certificate, then the information listed below will be needed. 
** Serial number of the revoked certificate
** Link to the OCSP response for that serial number
** Link to the CRL that contains that serial number
** notAfter date of the revoked certificate
** rfc5280 revocation reason code
* Process Change: To be determined, but may include changes to the Inclusion Process, and EV treatment (maybe EV treatment is only granted when the CA is providing this information?)


=== Preload Revocations of Certain End-Entity Certificates ===
=== Preload Revocations of Certain End-Entity Certificates ===
Kathleen Wilson
Confirmed users, Administrators
5,526

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1021052"

Navigation menu