On Mon, Sep 23, 2019 at 8:50 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:
> > > On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote: > > It would be useful to identify whether there’s an objective to the > questions, since that might help us cut down things quicker: > - Are you running a 5019 responder or a 6960 responder? > - Do you agree that the definition in 6960, Section 2.2, applies to > pre-certificates? > > If you are running a 6960 responder, and you don’t believe it applies to > pre-certificates, we should work that out first. > > > 2.2 applies to pre-certificates but between when the pre-certificate and > the final certificate is issued, there is a gap. > Got it. The point in trying to communicate is that with 2.2, the issuance of a precertificate is proof that it is “not non-issued”. This double negative is hard to parse, but it is essential: The gap comes up if you assume it’s trying to measure the issuance of C, the certificate, but it isn’t - it’s measuring when the CA doesn’t know if that serial number has been assigned. Because it’s measured by non-issuance, and the precertificate is proof of “not non-issuance” The only time where 6960 gets tricky is covered in Section 5: if a CA chooses to use authoritative revoked for non-issued and it uses sequential serial numbers. 5019 explains why you shouldn’t (and why you cannot, effectively), and 6960 leaves it optional. However, since no CA uses sequential serial numbers, there’s no reason to generate definitive revoked messages for “non-issued” certificates, and the existence of a precertificate is proof that it is “not non-issued” As I understand it, this is the main topic of this discussion, trying to > interpret the best course of action for this gap. If the responder was > allowed to respond with revoked and all the provisions of 6960 related to > "non-issued" certificates, until the final certificate is issued (if it is > ever issued), that seems like a safer option for Relying Parties because > they would not risk seeing a "valid" response for a Certificate that has > not been issued yet. > 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
