Confirmed users, Administrators
5,526
edits
CA:ImprovingRevocation: Difference between revisions
→Proposed Changes under Discussion
| Line 36: | Line 36: | ||
== '''Proposed''' Changes under Discussion == | == '''Proposed''' Changes under Discussion == | ||
The following changes are being discussed (or will be discussed) in | The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum. | ||
Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction of the discussion | Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion. | ||
=== Preload Revocations of Intermediate CA Certificates === | === Preload Revocations of Intermediate CA Certificates === | ||
| Line 49: | Line 49: | ||
* Dependencies: | * Dependencies: | ||
** The CAs in our program must notify us when intermediate certificates that chain up to any of their roots that are included in Firefox have been revoked. Mozilla will deliver these revocations to Firefox through the revocation set. For CAs that regularly revoke intermediate certificates, we will consider implementing a whitelist of intermediate certificates to prevent too many updates to the revocation set. | ** The CAs in our program must notify us when intermediate certificates that chain up to any of their roots that are included in Firefox have been revoked. Mozilla will deliver these revocations to Firefox through the revocation set. For CAs that regularly revoke intermediate certificates, we will consider implementing a whitelist of intermediate certificates to prevent too many updates to the revocation set. | ||
** In addition, the CAs in our program must notify us of | ** In addition, the CAs in our program must notify us of any mis-issuances and of any certificates that are to be revoked because some important constraint is missing or invalid (e.g. an end-entity certificate is given the statusResponder EKU, or a subscriber certificate was given the isCA=true basic constraint without meeting the requirements for such subscriber CA certificates). | ||
** The CA should send us details of the revocation, including the issuer subject name, the subject serial number, a link to the OCSP response for the revocation, and an assertion that the certificate was revoked for one of the reasons that we consider the issuing CA to be responsible for (they should say which reason it was). The easiest and best way to transmit this information is to simply attach the revoked certificate to the notification, assuming it contains the OCSP AIA URL. The link to the OCSP response that contains the revocation is needed to verify the authenticity of the email and to verify the exact encoding of the issuer and serial number. Note that this will require a bootstrapping effort where we ask all CAs to provide us with a comprehensive list of such revocations that occurred in the past. | ** The CA should send us details of the revocation, including the issuer subject name, the subject serial number, a link to the OCSP response for the revocation, and an assertion that the certificate was revoked for one of the reasons that we consider the issuing CA to be responsible for (they should say which reason it was). The easiest and best way to transmit this information is to simply attach the revoked certificate to the notification, assuming it contains the OCSP AIA URL. The link to the OCSP response that contains the revocation is needed to verify the authenticity of the email and to verify the exact encoding of the issuer and serial number. Note that this will require a bootstrapping effort where we ask all CAs to provide us with a comprehensive list of such revocations that occurred in the past. | ||
** In the short term, we will (probably) respond to the revocation notification by issueing 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. | ** In the short term, we will (probably) respond to the revocation notification by issueing 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 proposed and discussed in the mozilla.dev.security.policy forum. | * Policy Change: To be proposed and discussed in the mozilla.dev.security.policy forum. This draft still needs work. For instance, we should consider the notification policy expressed in NIST IR 7924, Section 5.7 (starting on page 36). However, we also want to take into account mis-issued end-entity certificates. | ||
** | ** EARLY DRAFT of text to add to MaintenancePolicy.html after item 3: 4. CAs must notify Mozilla within 24 hours of revocation of an intermediate certificate for any reason and of revocation of a website certificate whose revocation was not prompted by the certificate owner. To notify us of a revocation 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 | *** Serial number of the revoked certificate | ||
*** Link to the OCSP response for that serial number | *** Link to the OCSP response for that serial number | ||