On Tue, Sep 24, 2019 at 2:36 AM Clint Wilson <cl...@wilsonovi.com> wrote:
> On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Yup. And it’s been repeatedly acknowledged that is perfectly fine. The >> proposed language further considers that, but emphasizes that by producing >> and logging the precertificate, then regardless of the issue, the CA >> should >> be prepared to provision services for it for the duration. >> >> If you find yourself continually generating precertificates, that suggests >> an operational/design issue, which you can remediate based on which is >> cheaper for you: fixing the pipeline to be reliable (as many reliability >> issues seen, to date, have been on the CA side) or continue to provision >> services when things go bad. Either works, you can choose. >> >> The important part is you need to treat (pre-cert || cert) in scope for >> all >> your activities. You must be capable of revoking. You must be capable of >> searching your databases. You must be capable of validating. >> > > Agreed especially with the final paragraph here. > Apologies if this is too tangential, but one potential change I see coming > out of this discussion is around CT Log "outages". That is, separate from > the misconfiguration issues we've seen, one other instance where sometimes > pre-certificates are generated without an associated certificate is when CT > logs necessary for meeting a browser CT policy aren't available (as Andy > points out). Even if for very brief windows, today we occasionally see > windows where quite a few pre-certs can be generated but final certificate > issuance abandoned due to lack of SCTs (which is purely an implementation > choice as to when to abandon retries, I think). > Right. I think that's the substance of it. It's unclear to me what the benefit is of abandoning versus retrying later. I suspect it's a question of what the CA's window would be for (validation + SCTs), and if it's easier to kick it back into a validation flow if the SCT window elapses. Does that guess sound right? > Thinking through this discussion, it seems like one useful change for us > here may be to issue those final certs without the SCTs rather than > abandoning the pre-cert as we do today. We'd obviously still need to > re-attempt issuance of another cert with the SCT list (as that's what a > vast majority of customers expect), but reducing the number of orphaned > pre-certs seems like a reasonably good thing, even if inconsequential for > how we interact with the (pre-cert || cert). Does that seem like a > reasonable change in process to make? > It's not clear to me why this would be good or desirable? It doesn't seem to benefit the client/relying party ecosystem any. And it seems like it'd be more work for the CA to do. Perhaps I'm just not familiar with the set of CA problems it would solve? Could you help me out? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
