Re: [Trans] Precertificates and revocation

In the case of a precert subordinate CA, the CRLDP and AIA:ocsp will
contain the URLs of the real CA (the one that issued the precert sub CA).
How is it supposed to work? In a CTv1 world.

Le ven. 20 sept. 2019 à 15:52, Rob Stradling <rob@sectigo.com> a écrit :

> [This topic came up on mozilla.dev.security.policy recently.  Although
> the focus there is on the currently deployed CT v1 ecosystem, ISTM that
> TRANS should consider if/how CT v2 (6962-bis) should address the same
> issue]
>
> How should revocation servers behave when a precertificate exists but
> the corresponding certificate has not yet been (or will never be) issued?
>
> Should it be possible to revoke a precertificate when the corresponding
> certificate has not been issued?
>
> In RFC6962, precertificates are X.509 certificates, and so it's not
> unreasonable to expect OCSP responders to be able to provide their
> status.  However, 6962-bis precertificates are not X.509 certificates,
> which I think changes what might or might not be a reasonable expectation.
>
> Andrew points out (see forwarded message below) that outside observers
> have to assume that a certificate has been issued when they see a
> corresponding precertificate (since the presumed-to-exist certificate
> may never be submitted to a log), and that outside observers will expect
> CAs to operate revocation services for the presumed-to-exist certificates.
>
> Back to CT v1: Mozilla now requires [1] 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."
>
> ISTM that we should address this topic in 6962-bis somehow, but what do
> folks think we could say without straying into "policy"?
>
>
> [1]
>
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
>
>
> -------- Forwarded Message --------
> Subject: Re: DigiCert OCSP services returns 1 byte
> Date: Mon, 16 Sep 2019 10:08:00 -0700
> From: Andrew Ayer <agwa@andrewayer.name>
> To: Rob Stradling <rob@sectigo.com>
> CC: dev-security-policy@lists.mozilla.org
>
> On Fri, 13 Sep 2019 08:22:21 +0000
> Rob Stradling via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>
> > Thinking aloud...
> > Does anything need to be clarified in 6962-bis though?
>
> Yes, it's long past time that we clarified what this means:
>
> "This signature indicates the CA's intent to issue the certificate.  This
> intent is considered binding (i.e., misissuance of the precertificate is
> considered equivalent to misissuance of the corresponding certificate)."
>
> The goal is that a precertificate signature creates an unrebuttable
> presumption that the CA has issued the corresponding certificate. If a
> CA issues a precertificate, outside observers will treat the CA as if
> it had issued the corresponding certificate - whether or not the CA
> really did - so the CA should behave accordingly.
>
> It's worth explicitly mentioning the implications of this:
>
> * The CA needs to operate revocation services for the corresponding
> certificate as if the certificate had been issued.
>
> * If the corresponding certificate would be misissued, the CA will be
> treated as if it had really issued that certificate.
>
> Are there any other implications that 6962-bis should call out
> explicitly?
>
> Regards,
> Andrew
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
-- 
Erwann.