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 <[email protected]> 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 <[email protected]> > To: Rob Stradling <[email protected]> > CC: [email protected] > > On Fri, 13 Sep 2019 08:22:21 +0000 > Rob Stradling via dev-security-policy > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/trans > -- Erwann.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
