(In reply to Aaron Gable from comment #0) > ### 5. In a case involving certificates, the complete certificate data for the problematic certificates. > > See Bug 1715455. This (and Bug 1715455) don't appear to provide the required detail. This is something that CAs have been expected to provide, which hopefully Let's Encrypt will see through the review of other CA incidents, as mentioned in Bug 1715455. As captured in the incident template: > The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any. > While we appreciate that reporting and discussing this incident may lead to improvements to our CA and the PKI ecosystem going forward, in this case we do not believe that revoking certificates already issued as part of our response would benefit the Web PKI. Have I missed an explanation as to why? This appears to just be a statement of opinion, without supporting details. This seems to borderline the unacceptable response, namely: > The rationale must include an explanation for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable Again, this is something that Let's Encrypt would be aware of through review of other CA incidents. > All of the certificates in question have a validity period of approximately 23% the maximum allowable validity period as per the BRs. Thus, this extra one second of validity is still far short of the Baseline Requirements’ maximum allowable lifespan. Yes, but the BRs also require revocation if: > 7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; In essence, the statement provided here is why Let's Encrypt feels it is OK to not revoke, which may be a factor for consideration, but it's missing the analysis requested by https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation . This should be easy to provide, but it's concerning that it's not provided here. > Many certificate consumers (such as Chrome and NSS) treat affected certificates as having a 90-day lifespan, not 90 days plus 1 second. "Show, don't tell" :) I would normally flag this as a particularly problematic statement, because it lacks supporting detail. This is, however, partly mitigated because you did show the work in the related thread at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-BogZx_IJyk/m/gHm3l613AgAJ relating to this incident, close to the time of posting this report. In the future, please ensure incident reports have the relevant supporting details. > Finally, based on the implementation of those certificate consumers and based on discussion on both Bug 1715455 and [Bug 1708965](https://bugzilla.mozilla.org/show_bug.cgi?id=1708965), it is not clear that there is widespread consensus across the WebPKI ecosystem that (absent the precedent of Bug 1708965) this constitutes misissuance. We intend to raise this discussion on MDSP to provide clarity for future potential incidents. The relevant thread is https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-BogZx_IJyk/m/gHm3l613AgAJ , and corrections have been provided on that thread. Note that as part of Let's Encrypt's analysis here, relevant other discussions were overlooked, as captured in Bug 1715672, Comment #19 , that show that there has been a historic consensus on the expectation, both from software vendors and CAs. > We will commit additional effort to bring ARI through the IETF standardization process. This is not a binding timeline, as expected at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report I realize that trying to get a timeline out of the IETF is like trying to get praise for a CA from me - i.e. incredibly difficult - but the expectation here is that Let's Encrypt is going to provide an objective baseline to measure progress, where their prioritization and goals are (e.g. when THEY would like to have something implemented), and periodic updates on that. Obviously, there is benefit to consensus-based standards development, but the concern here, as has happened with other CAs, is that the desire for "consensus" is a way of making it somebody else's problem. This is because consensus doesn't form in a vaccuum, and requires energy and investment, and the goal of this incident report is to understand the energy and investment being placed by Let's Encrypt to prevent these incidents going forward.
Bug 1715672 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Aaron Gable from comment #0) > ### 5. In a case involving certificates, the complete certificate data for the problematic certificates. > > See Bug 1715455. This (and Bug 1715455) don't appear to provide the required detail. This is something that CAs have been expected to provide, which hopefully Let's Encrypt will see through the review of other CA incidents, as mentioned in Bug 1715455. As captured in the incident template: > The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any. > While we appreciate that reporting and discussing this incident may lead to improvements to our CA and the PKI ecosystem going forward, in this case we do not believe that revoking certificates already issued as part of our response would benefit the Web PKI. Have I missed an explanation as to why? This appears to just be a statement of opinion, without supporting details. This seems to borderline the unacceptable response, namely: > The rationale must include an explanation for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable Again, this is something that Let's Encrypt would be aware of through review of other CA incidents. > All of the certificates in question have a validity period of approximately 23% the maximum allowable validity period as per the BRs. Thus, this extra one second of validity is still far short of the Baseline Requirements’ maximum allowable lifespan. Yes, but the BRs also require revocation if: > 7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; In essence, the statement provided here is why Let's Encrypt feels it is OK to not revoke, which may be a factor for consideration, but it's missing the analysis requested by https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation . This should be easy to provide, but it's concerning that it's not provided here. > Many certificate consumers (such as Chrome and NSS) treat affected certificates as having a 90-day lifespan, not 90 days plus 1 second. "Show, don't tell" :) I would normally flag this as a particularly problematic statement, because it lacks supporting detail. This is, however, partly mitigated because you did show the work in the related thread at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-BogZx_IJyk/m/gHm3l613AgAJ relating to this incident, close to the time of posting this report. In the future, please ensure incident reports have the relevant supporting details. > Finally, based on the implementation of those certificate consumers and based on discussion on both Bug 1715455 and [Bug 1708965](https://bugzilla.mozilla.org/show_bug.cgi?id=1708965), it is not clear that there is widespread consensus across the WebPKI ecosystem that (absent the precedent of Bug 1708965) this constitutes misissuance. We intend to raise this discussion on MDSP to provide clarity for future potential incidents. The relevant thread is https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-BogZx_IJyk/m/gHm3l613AgAJ , and corrections have been provided on that thread. Note that as part of Let's Encrypt's analysis here, relevant other discussions were overlooked, as captured in Bug 1715455, Comment #19 , that show that there has been a historic consensus on the expectation, both from software vendors and CAs. > We will commit additional effort to bring ARI through the IETF standardization process. This is not a binding timeline, as expected at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report I realize that trying to get a timeline out of the IETF is like trying to get praise for a CA from me - i.e. incredibly difficult - but the expectation here is that Let's Encrypt is going to provide an objective baseline to measure progress, where their prioritization and goals are (e.g. when THEY would like to have something implemented), and periodic updates on that. Obviously, there is benefit to consensus-based standards development, but the concern here, as has happened with other CAs, is that the desire for "consensus" is a way of making it somebody else's problem. This is because consensus doesn't form in a vaccuum, and requires energy and investment, and the goal of this incident report is to understand the energy and investment being placed by Let's Encrypt to prevent these incidents going forward.
(In reply to Aaron Gable from comment #0) > ### 5. In a case involving certificates, the complete certificate data for the problematic certificates. > > See Bug 1715455. This (and Bug 1715455) don't appear to provide the required detail. This is something that CAs have been expected to provide, which hopefully Let's Encrypt will see through the review of other CA incidents, as mentioned in Bug 1715455. As captured in the incident template: > > The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any. > While we appreciate that reporting and discussing this incident may lead to improvements to our CA and the PKI ecosystem going forward, in this case we do not believe that revoking certificates already issued as part of our response would benefit the Web PKI. Have I missed an explanation as to why? This appears to just be a statement of opinion, without supporting details. This seems to borderline the unacceptable response, namely: > > The rationale must include an explanation for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable Again, this is something that Let's Encrypt would be aware of through review of other CA incidents. > All of the certificates in question have a validity period of approximately 23% the maximum allowable validity period as per the BRs. Thus, this extra one second of validity is still far short of the Baseline Requirements’ maximum allowable lifespan. Yes, but the BRs also require revocation if: > > 7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; In essence, the statement provided here is why Let's Encrypt feels it is OK to not revoke, which may be a factor for consideration, but it's missing the analysis requested by https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation . This should be easy to provide, but it's concerning that it's not provided here. > Many certificate consumers (such as Chrome and NSS) treat affected certificates as having a 90-day lifespan, not 90 days plus 1 second. "Show, don't tell" :) I would normally flag this as a particularly problematic statement, because it lacks supporting detail. This is, however, partly mitigated because you did show the work in the related thread at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-BogZx_IJyk/m/gHm3l613AgAJ relating to this incident, close to the time of posting this report. In the future, please ensure incident reports have the relevant supporting details. > Finally, based on the implementation of those certificate consumers and based on discussion on both Bug 1715455 and [Bug 1708965](https://bugzilla.mozilla.org/show_bug.cgi?id=1708965), it is not clear that there is widespread consensus across the WebPKI ecosystem that (absent the precedent of Bug 1708965) this constitutes misissuance. We intend to raise this discussion on MDSP to provide clarity for future potential incidents. The relevant thread is https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-BogZx_IJyk/m/gHm3l613AgAJ , and corrections have been provided on that thread. Note that as part of Let's Encrypt's analysis here, relevant other discussions were overlooked, as captured in Bug 1715455, Comment #19 , that show that there has been a historic consensus on the expectation, both from software vendors and CAs. > We will commit additional effort to bring ARI through the IETF standardization process. This is not a binding timeline, as expected at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report I realize that trying to get a timeline out of the IETF is like trying to get praise for a CA from me - i.e. incredibly difficult - but the expectation here is that Let's Encrypt is going to provide an objective baseline to measure progress, where their prioritization and goals are (e.g. when THEY would like to have something implemented), and periodic updates on that. Obviously, there is benefit to consensus-based standards development, but the concern here, as has happened with other CAs, is that the desire for "consensus" is a way of making it somebody else's problem. This is because consensus doesn't form in a vaccuum, and requires energy and investment, and the goal of this incident report is to understand the energy and investment being placed by Let's Encrypt to prevent these incidents going forward.