On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Sep 23, 2019 at 11:53 PM Andy Warner via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > 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.
>
>
> As others have pointed out, it sounds like GTS is confused. This only
> applies if you need to revoke them.
>
> I’m not sure how many times it bears repeating, but the suggestion that you
> need to revoke if you issued a precert, but not the cert, is patently
> absurd. Among other things, as you point out, it causes both CRL and OCSP
> growth.
>
> Luckily, every browser participating has seemingly tried to make it clear
> that’s not expected. So one objection handled :)
>
> 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.
>
>
> Could you point to an example? All of the conversation I’ve seen has
> highlighted that they are sequential, and can suffer a variety of delays or
> errors. This is why the conversation has been about the least error prone
> approach, in that it leads to the most consistent externally observable
> results.
>
> I admit, I’m honestly not sure what part of the conversation is being
> referred to here.
>
> As a result of this, the existence of a precertificate is possible without
> > a final certificate having been issued.
>
>
> 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).
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?


>
> 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.
>
>
> It doesn’t, because it’s a flawed understanding that’s been repeatedly
> addressed: you don’t have to issue the final certificate. But you MUST be
> prepared to provision services as if you had.
>
> In general, this means you provision and distribute those services ahead of
> time. My reply to Dimitris earlier today provided a road map to an error
> prone design, as well as two different ways of accomplishing compliant
> design. Given that GTS is responding to that thread, I’m surprised to see
> it come up again so quickly, as it seems like GTS may not have understood?
>
>
> 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.]
>
>
> I cannot see how it redefined relying party, as anyone who decides to trust
> GTS becomes a relying party of GTS, and does not change anything.
>
> The question of how soon has been mentioned earlier, but again is addressed
> by earlier replies. We’ve seen the problems with CAs arguing CDN
> distribution. There is no reasonable way that the relying party community
> can or should accept the phased rollout delays as compliant, particularly
> with a 24 hour revocation timeline (for example).
>
> A common approach to this is to pregenerate responses for distribution,
> with edge caches (5019-style) that can talk to an authoritative origin
> (6960-style) under the hood. If a client queries for the status, the edge
> cache serves it if it’s a cache hit, otherwise communicates back to the
> origin and pulls into the cache. This is perhaps unsurprising, as it’s the
> model many active CDNs use, functioning as it were as a reverse proxy with
> caching (and the ability to globally evict from the cache).
>
> Since the CA already needs to ensure that they can have a globally
> consistent response distributed within 24-hours, and that any time spent
> synchronizing is time that the CA itself cannot use to investigate/respond,
> this design discourages CAs from multihour rollouts (and that’s a good
> thing). If you can’t meet those timelines, then you’re setting yourself up
> for a CA incident that other CAs will have designed around.
>
> If you think through the logical consequences for relying parties, it’s
> clear that there are approaches CAs can use that are harmful, and there are
> approaches they can use that are helpful. As publicly trusted CAs, they are
> expected to be beyond reproach, and make every decision with the relying
> parties’ interests at heart: not the Subscriber’s, not the Applicant’s, not
> the CA’s. Something about putting the user first, and the user here is
> everyone that will trust a certificate from that CA.
>
> 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."
>
>
> It’s not ambiguous.
>
> Read 4.9.1.1 and 7.1.2.3(c). You aren’t providing a responder if it can’t
> answer for four days, and you aren’t meeting the revocation timeline if you
> aren’t publishing revocation information in 24 hours.
>
> The normal timeline:
> - Upon issuance, the definitive response is available
> - That definitive response is refreshed at least every four days
>   - While the BRs max is ten days, a reminder that Microsoft sets a minimum
> of 8 hours, requires the maximum be 7 days, and new information available
> at half that - e.g. 3.5 days
> - The responder should maintain global consistency (e.g. if using RFC5019,
> this is easier)
>
> When revoking:
> - That response should be globally available and published with 24 hours or
> five 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.
>
>
> Again, it sounds like GTS hasn’t been following the thread or the updates,
> which have clarified as to why the presumed gap (between precert and cert)
> is irrelevant, and thus a lower bound not needed here. This only becomes an
> issue if GTS is responding unknown for several hours after issuing certs -
> but by that logic, GTS is not providing responders for several hours after
> issuance, which is a BR violation today.
>
> * Clarifications
> >
> > This in turn raises the question if CAs can re-use authorization data
> such
> > as CAA records or domain authorizations from the precertificate?
>
>
> It doesn’t, because the BRs answer this, if GTS reads them. Specifically,
> 3.2.2.8 answers this for CAA.
>
> 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?
>
>
> It seems a responsible CA would answer “No”, and ensure that the validity
> period of any information they use is good for (pre-cert issuance time +
> time they’re willing to wait for SCTs). They would avoid this whole issue,
> by avoiding trying to do the “least possible” and recognizing that they
> have the flexibility to unambiguously avoid any compliance issues here.
>
> 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.
>
>
> This is entirely unproductive and unhelpful, because it talks around the
> issue. This is the behaviour we the community largely see of problematic
> CAs that don’t have user’s security first.
>
> If you think there’s an issue with the date, a productive, useful
> contribution, would be:
> - Highlight when
> - Highlight why
>
> However, none of the discussion “should” be a functional change for any CA
> following the rules. Even as a clarification of expectations, it’s trivial
> to resolve and get into compliance, judging by the responses we’ve seen
> from CAs to date.
>
> I’m most encouraged, and most discouraged, that it seems even still today,
> GTS is having trouble understanding what’s proposed, and seeing things that
> simply aren’t there, rather than the things that are. Hopefully, the
> clarifications to this thread, showing GTS has not followed the
> conversation, do much to assuage the concerns that GTS is being asked to
> implement major changes. The only major change I can see is it sounds like
> GTS may have had other compliance issues with its responder services,
> likely similarly based on misunderstanding the requirement as a publicly
> trusted CA. As I said, that’s encouraging and discouraging.
>
> I know that’s far more direct than Wayne would be, but any publicly trusted
> CA that’s been following this Forum should recognize that GTS is following
> a playbook used by CAs to push back on security improvements
> unconstructively, as a stalling tactic that usually exists to hide or paper
> over non-compliance, and then arguing the non-compliance was because of
> something ambiguous, rather than thinking through the logical consequences
> of their decisions.
>
> This isn’t to say pushing back gets you branded as a poor CA; however, this
> specific approach, still lacking in actionable data and misunderstanding
> both Root Policy and the CA/B Forum, absolutely causes a crisis of
> confidence in the CAs that do this, and for good reason, as time has born
> out.
>
> 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.
>
>
> This is ahistorical. The historic precedent is and has been root program
> requirements, especially with respect to matters like the topic at hand,
> eventually flowing into the BRs.
>
> That a CA would suggest that the CA/B Forum is a better place for
> discussing this than here deeply saddens me, precisely because of the
> intentional exclusion of a number of people from the Forum that have made
> incredibly valuable and worthwhile contributions. Honestly, I suppose I had
> expected GTS to value the openness and transparency this provides over the
> Forum.
>
> It is true that CAs bear the responsibility of following the rules of the
> root programs they are in, and that can be complex if those requirements
> aren’t centrally codified. A trivial solution exists for this, but which
> CAs rarely avail themselves of: they can draft text (if they aren’t voting
> members) or prepare and sponsor ballots (if they are) to incorporate the
> root program requirements into text. For example, I continue to remain
> shocked that no CA has thought to do so with Microsoft’s OCSP requirements,
> or both Microsoft and Mozilla’s EKU requirements.
>
> However, since this neither changes the expectations in the BRs nor
> requires anything new of CAs, and merely explains the logical consequences
> of RFC5019/6960 to those who may struggle with it, it does not seem to at
> all raise to the level suggested here.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to