The CRL question is not about it being a requirement, but rather the fact that it could / would lead to disparate treatment between CRL and OCSP for the same certificate, which does not feel right.
On the CT quorum issue, we use a mix of the most available sharded logs and that is the failure rate we're observing. We have a few ideas for improvements we're working on. If other operators are seeing much different success rates, we'd love to compare notes. We're using the published best practices, spreading load and using sharded logs, so an implementation issue is not obvious if there is one. That said, other groups within Google including the CT team also exchange messages with CT logs in fairly high volumes, so we may experience atypically high rate-limiting due to all being bucketed together. CAA validations are only good for 8 hours, so the suggestion of a year misses the much shorter timeline that needs to be honored for CAA. -- Andy Warner Google Trust Services On Mon, Sep 23, 2019 at 3:57 PM Kurt Roeckx <k...@roeckx.be> wrote: > On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via > dev-security-policy wrote: > > > > 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. > > There have been suggestions to revoke them, but it's my > understanding that there is no such requirement. > > > 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. > > I don't see anybody suggesting that, nor how it's relevant. > > With all the uptime requirements on the logs and the number of > available logs, I don't see why you should have a failure rate > of 1 in 2000, and that more seems like an implementation problem. > > > 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. > > At what is the issue with that? > > > * 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? > > So 1 year is sometimes not enough to get SCTs? > > > Kurt > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
