On Tue, Sep 24, 2019 at 5:06 AM Ryan Sleevi <r...@sleevi.com> wrote:

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

Yeah, that's exactly right. That's also partially because we don't cache
CAA for 8 hours, so we could instead widen the window of retries as well.

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

So I'm not totally confident that it is good or desirable, but my thought
was more along the lines of cognitive benefits than operational. It's
apparently somewhat difficult to grok that "cert" interactions need to
apply to pre-certs, so if CAs moved away from abandoning pre-certs
(wherever possible), then a lot of the behavior changes discussed here
would happen automatically. That is, we have to put in a fix for ensuring
services are available either way for (pre-certs || certs), but if there is
more reliably (pre-cert && cert) available then the services are (from what
I can see) already available for CAs. Maybe that's a change that can occur
ahead of patches for the misconfiguration issues.
Since all of that's relatively short-term benefits, I'm probably not
approaching this the best way, but that was the thought.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to