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 

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

Reply via email to