On 17/09/2019 00:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling <r...@sectigo.com> wrote:
>
>> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
>> <snip>
>>
>> If a certificate (with embedded SCTs and no CT poison extension) is
>> "presumed to exist" but the CA has not actually issued it, then to my
>> mind that's a "certificate that has not been issued"; and therefore, the
>> OCSP 'responder SHOULD NOT respond with a "good" status'.
>>
>> However, this is Schrödinger's "certificate that has not been issued",
>> because a Precertificate has been issued that has the same serial number
>> (as the "certificate presumed to exist" that doesn't actually exist).
>>
>> And so at this point ISTM that the OCSP responder is expected to
>> implement two conflicting requirements for the serial number in question:
>> (1) MUST respond "good", because an unrevoked/unexpired
>> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
>> response).
>> (2) SHOULD NOT respond "good" (see BR 4.9.10).
>>
>>
> If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
> on to state "Effective 1 August 2013, OCSP responders for CAs which are not
> Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
> "good" status for such certificates." (referring to 'certificates that have
> not been issued' from the prior paragraph)
>
> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in Mozilla
> policy, but I'd want to get the BRs updated quickly as Rob suggested to
> avoid audit findings.
>
> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
> provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding "unknown"
> to precertificates without corresponding certificates are doing the right
> thing, despite prior precedent indicating that this is a violation. [1]
>
In any networked system, delays are inevitable.
If data (in this case replication status data) is to be reliably
replicated, there will be a further delay to ensure that bad data is
not forced onto all mirrors too quickly (Consider earlier incident(s)
where corrupted revocation data was rolled out to all the servers used
by a CA. Also consider the delay in the recent rollout of incident-
initiated revocations by GTS).
Thus it is technically inevitable that some revocation servers will
respond "unknown" for a freshly issued (as in signed) certificate.
So the real question is which of the various steps in a CT-logged
issuance are allowed to happen while the certificate status is
replicated to all the OCSP and CRL servers operated by a CA.
It is of cause possible to pretend that a signed but not yet submitted
certificate and/or preCertificate doesn't exist, creating a strict
serialization of steps:
1. Allocate serial number and other content.
2. Replicate this allocation to survive crashes.
3. Sign the preCertificate, canned "good" OCSP responses and a fresh
CRL (if the CRL contains extensions describing the valid serial
numbers).
4. Replicate the preCertificate and OCSP responses to survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature).
5. Wait for all those OCSP responses and CRLs to reach all mirrors.
6. Record the completion of this rollout in the replicated dataset.
7. Submit the preCertificate to CT logs (which unnecessarily check
that the mirrors report "good" instead of "unknown" according to
the strict policy);
8. Wait for all the CT logs to return SCTs.
9. Replicate the SCTs to survive crashes.
(failure during this step will require extracting SCTs from the
CT logs or revoking the preCertificate and starting over).
10. Sign the actual certificate and any further canned OCSP responses
and CRLs that refer to the contents or signature of the actual
certificate.
11. Replicate the actual certificate and any new revocation data to
survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature,
alternatively revoke and start over).
12. Wait for any such OCSP responses and CRLs to reach all mirrors.
13. Record the completion of this rollout in the replicated dataset.
(Failure during this step results in having to check the rollout
status again).
14. Submit the actual certificate to CT logs and await acknowledgement.
15. Finally send the actual certificate to the subscriber.
My alternative 4 paragraph proposal (rest was rationale) was to accept
the existence of delays, aim for eventual consistency, maximize overlap
between the operations by allowing the initial CT submission to happen
before all revocation servers respond "good" and the delivery to
subscriber to also happen during the wait for rollout.
As for my alleged use of magic numbers, this was the result of a logical
deduction: When revoking a misissued certificate that may have produced
stored signatures (TLS isn't everything), the revocation data should
state that the certificate was never valid and any such stored
signatures are thus invalid. Within the limitations of existing OCSP
and CRL formats, this is most effectively done by backdating the
revocation time in responses/CRLs to before the certificate would
otherwise have become valid. Cryptographically stating that due to any
number of failure scenarios (see the incidents in this thread) the
actual certificate was never issued, could be similarly stated by
stating an even earlier revocation of the hypothetical certificate.
Trying to think forward, I proposed leaving a reserved margin between
the two revocation timestamp ranges. A more clumsy alternative would
be to insert a special extension in the revocation data, with a
resulting OID allocation etc.
> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
>
>
>> Clearly that's impossible, which leads to the question: Which of these
>> two conflicting requirements should a CA ignore in order to be as
>> un-non-compliant as possible? Which leads me to BR 7.1.2.5:
>> 'For purposes of clarification, a Precertificate, as described in RFC
>> 6962 – Certificate Transparency, shall not be considered to be a
>> “certificate” subject to the requirements of RFC 5280'
>>
>> Since the first mention of "certificates" in the OCSP Protocol Overview
>> (RFC6960 section 2) cross-references RFC5280, I believe that this 'shall
>> not be considered to be a "certificate"' declaration can be assumed to
>> extend to the OCSP requirements too. And therefore, the balance tilts
>> in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST
>> respond "good"'.
>>
>> I can't say I like this conclusion, but nonetheless it is the conclusion
>> that my reading of the BRs forces me to reach. I realize that what the
>> BRs actually say may not reflect precisely what was intended by
>> CABForum; nonetheless, CAs are measured by what the BRs actually say.
>>
>> IDEAS FOR FIXING IT:
>>
>> Long-term:
>> - In CT v2 (6962-bis), precertificates are not X.509 certificates,
>> which removes Schrödinger from the equation. :-)
>>
>> Short-term:
>> - I think BR 7.1.2.5, as written, is decidedly unhelpful and should
>> be revised to have a much smaller scope. Surely only the serial number
>> uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
>> not the entirety of RFC5280?
>> - I would also like to see BR 4.9.10 revised to say something roughly
>> along these lines:
>> 'If the OCSP responder receives a status request for a serial number
>> that has not been allocated by the CA, then the responder SHOULD NOT
>> respond with a "good" status.'
>>
>> P.S. Full disclosure: Sectigo currently provides an (unsigned)
>> "unauthorized" OCSP response when a precert exists but the corresponding
>> cert doesn't, but in all honesty I'm not currently persuaded that an
>> Incident Report is warranted.
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> Email: r...@sectigo.com
>>
>>
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
