I have gone ahead and added a section titled "Precertificates" [1] to the
Required Practices wiki page.

I have also updated a policy issue [2] suggesting that this be moved into
the Root Store policy, and added a new issue [3] suggesting that we clarify
the acceptable use of the "unknown" OCSP response.

I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR

- Wayne

[2] https://github.com/mozilla/pkipolicy/issues/138
[3] https://github.com/mozilla/pkipolicy/issues/189

On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer <wtha...@mozilla.com> wrote:

> Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
> and Ryan's:
> The current implementation of Certificate Transparency does not provide
>> any way for Relying Parties to determine if a certificate corresponding to
>> a given precertificate has or has not been issued. It is only safe to
>> assume that a certificate corresponding to every precertificate exists.
>> RFC 6962 states “The signature on the TBSCertificate indicates the
>> certificate authority's intent to issue a certificate.  This intent is
>> considered binding (i.e., misissuance of the Precertificate is considered
>> equal to misissuance of the final certificate).”
>> However, BR states “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 - Internet X.509 Public Key Infrastructure Certificate and Certificate
>> Revocation List (CRL) Profile under these Baseline Requirements.”
>> Mozilla interprets the BR language as a specific exception allowing CAs
>> to issue a precertificate containing the same serial number as the
>> subsequent certificate [1]. Otherwise, Mozilla infers from the existence of
>> a precertificate that a corresponding certificate has been issued.
>> This means, for example, that:
>> * A CA must provide OCSP services and responses in accordance with
>> Mozilla policy for all certificates presumed to exist based on the presence
>> of a Precertificate, even if the certificate does not actually exist
>> * A CA must be able to revoke a certificate presumed to exist, if
>> revocation of the certificate is required under Mozilla policy, even if the
>> certificate does not actually exist.
>> * If any corresponding certificate with the same serial number and issuer
>> exists, and can not be verified to match the precertificate using the
>> algorithms in RFC 6962, it will be considered misissued.
>> * In examining historical issuance, the CA must consider both final
>> certificates and precertificates, even if the precertificate did not
>> ultimately result in the issuance of a certificate.
> I propose adding this language to our "Required Practices" wiki page [2],
> then introducing a CAB Forum ballot that limits the scope of BR to
> serial numbers. That still leaves some uncertainty about the use of the
> "unknown" response for precertificates (and in general), although Ryan made
> some good points about why using this status beyond the very narrow scope
> described in RFC 6960 section 2.2 is a bad idea.
> Once again, I will greatly appreciate your feedback on this topic. Since
> this is a practice and not official policy, I'll go ahead and update the
> wiki when I sense that we're in agreement here.
> - Wayne
> [1] https://cabforum.org/pipermail/public/2014-January/002694.html
> [2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
> On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org <mailto:
>> dev-security-policy@lists.mozilla.org>> wrote:
>> >
>> >>
>> >>
>> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> >> dev-security-policy@lists.mozilla.org> wrote:
>> >>>
>> >>> Hi Kurt.  I agree, hence why I proposed:
>> >>>
>> >>>  "- 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.’"
>> >>
>> >> I suppose one issue there is for CAs which allocate the serial number
>> very
>> >> early on in the issuance workflow - signing a dummy certificate with an
>> >> untrusted key, for instance, but not committing the CA to actually
>> >> producing either a pre-certificate or certificate (e.g, because the
>> >> applicant has insufficient funds to complete the process). It would not
>> >> seem correct to start answering (affirmatively) OCSP requests where no
>> >> artefact has been signed by a trusted key.
>> >>
>> >
>> > Why does a CA need to sign something to allocate a serial? Could you
>> expand
>> > a bit more on that?
>> >
>> Yes - on further consideration, I could have been a lot clearer. I didn’t
>> mean that a CA _has_ to sign something to allocate a serial in some
>> internal database; merely that the allocation of a serial number, in
>> itself, isn’t the trigger (in my opinion, of course) for any OCSP server to
>> start responding to the (Issuer, Serial Number) request with successful
>> response codes.
>> What I meant was that some workflows allocate a serial number, sign a
>> dummy certificate containing that serial number (with an untrusted key),
>> which then flows through with linting checks, and so on. But the decision
>> to sign the said certificate with a trusted key has not yet been made
>> (officially). But when any object (precertificate, certificate) containing
>> that allocated serial number gets signed with a trusted key, it is a
>> reasonable expectation for relying parties to be able to query OCSP
>> services and not get a “Never heard of it” answer (whether that’s a RFC
>> 6960 4.4.8 response, or an “unauthorized”, or whatever).
>> In other words, Rob’s original language which refers purely to the
>> (CA-internal) allocation of the serial number as the triggering event seems
>> not to cover all relevant cases. Not that I’ve been able to come up with
>> any better language, I should add.
>> Regards,
>> Neil
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
dev-security-policy mailing list

Reply via email to