The last thing we intended was for our prior mail to be interpreted as negative and without substance. That said, it is clear our mail was not received in the light in which it was intended.
We would like to rectify that. We have been closely monitoring this thread and as it began to converge on a conclusion we started planning for each of our CA environments what if any changes would be required and what solutions compliant with our understanding of the conclusions would look like. With that background, our understanding is that the goal of this change is to make it easier to monitor the issuance and revocation practices of a CA based on the existence of precertificates, i.e. extending the use of certificate revocation data to include this monitoring use case. We see value in this and are supportive of the overall change, as it is clear that CT, as a whole, has made significant quality improvement to the WebPKI as a whole and this provides additional incremental benefit. However, we see several challenges that we want to discuss, in particular: 1. The new text added to the Mozilla Recommended and Required Practices for this topic states only OCSP status is required for precertificates. Many CAs provide both CRLs and OCSP services and it would be problematic if these two mechanisms provided different answers to the same question. The practice of revoking non-issued certificates would therefore lead to CRL growth which would further make reliable revocation checking on bandwidth constrained clients more difficult. Though this tax may be deemed acceptable, there is a clear impact and GTS feels that increasing CRL sizes for this use case is not in the best interest of users. We can see both sides of the argument, but we think a bit more detail is required to ensure our implementations align with best practices and user interests. 2. There seem to be a number of assumptions that precertificate issuance and certificate issuance is roughly atomic. In reality, a quorum of SCTs is required prior to final certificate issuance, so that is not the case. CAs are rate limited by logs or logs experience availability issues that make achieving quorum require retries or fail altogether. GTS, for example, experiences approximately 0.05% delays / order abandonment related to an inability to achieve quorum. As a result of this, the existence of a precertificate is possible without a final certificate having been issued. With the wider availability of sharded logs, this number has been improving, but it continues to be our most common cause of issuance delay or order abandonment. 3. This raises the question of how much time a CA has from the time they issue a precertificate to when the final certificate must be issued. When there are logs ecosystem issues that are beyond the control of a CA, the gap can easily be orders of magnitude higher than normal operating conditions. Likewise, there is the question of how soon the revocation information must be produced and reachable by an interested party (e.g. someone who has never seen the certificate in question but still wants to know the status of that certificate). [Aside, Wayne, you specifically said relying parties earlier, did you intend to say interested party or relying party? We have some additional questions if relying party was actually intended, as using it in that context seems to redefine what a relying party is.] This “reachable” part is particularly meaningful in that when using a CDN there are often phased roll outs that can take hours to complete. Today, the BRs leave this ambiguous, the only statement in this area is that new information must be published every four days: "The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days." With this change, it would seem there needs to be a lower bound defined for how quickly the information needs to be available if it is to be an effective monitoring tool. * Clarifications This in turn raises the question if CAs can re-use authorization data such as CAA records or domain authorizations from the precertificate? If a final certificate has not been issued due to a persistent quorum failure, and that failure persists longer than the validity of the used authorization data, can the authorizations that were done prior to the precertificate issuance be re-used? If the precertificate is a promise to issue the exact same cert, it would seem to imply yes, but there are plenty or real world scenarios where that would not be sensible or in-line with the requester's intent. If the CAA record changes between initial validation for the precertificate and re-validation for actual issuance if there were delays, what is the correct course of action? * Process On Thursday last week, Wayne added the topic to Recommended and Required Practices (https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates) as a “requirement”. It is entirely the right of each browser to have their own technical requirements, in this particular case it seems that implementation changes will be needed in several CA software packages and in-house implementations to meet this interpretation. As such, in our opinion, a roll out period to enable software and deployment changes to be made would be appropriate. Had this conversation taken place within the CA/Browser forum, the implementation date would have been discussed before becoming a formal requirement. We leave it to Browsers to determine reasonable timelines and we're not seeking to delay, simply recognition that many changes take time to implement and it is tough to effectively respond to changes that become new requirements in an instant. Browsers should set whatever requirements they believe are in the best interest of their users, but the more requirements are split across multiple root program's requirements, the CA/Browser Forum and IETF, the harder it becomes to reason about what a correct behavior is. Given the historical precedent of rule making in CA/Browser forum and the fact that it covers all participants, it seems like the ideal body to ensure consistency within the ecosystem. As a community body with often divergent viewpoints, we acknowledge that users are not always best served by waiting on change via the CA/B Forum. In a case like this, Browsers making recommendations on their preferred practices without being overly prescriptive initially helps ensure the community is moving in the right direction. If formal clarification via the CA/B Forum is not proceeding quickly enough, shifting from recommendations to requirements may well be appropriate on a timeline commensurate to the severity of the issue. -- Andy Warner Google Trust Services On Monday, September 23, 2019 at 9:21:26 AM UTC-7, Dimitris Zacharopoulos wrote: > On 2019-09-23 5:00 μ.μ., Ryan Sleevi via dev-security-policy wrote: > > No. That’s the more dangerous approach which I’ve tried repeatedly to > > dissuade. You should produce, and distribute, the Good response with the > > pre-certificate. > > Understood. Thank you for the clear guidance. > > Dimitris. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
