The BRs and Mozilla program policies don't support the idea of just trusting a CA to issue certs for "internal" use or to keep them secret. This is why CAs issuing "test certificates" on production CAs for domains they don't own is clearly forbidden.
Given that, I don't see how it can be acceptable to provide an "unknown" status over OCSP for a revoked certificate, on the premise that the CA asserts they never actually shipped the cert to a customer. The fact that they would have to mark the cert "valid" before marking it "revoked" is a limitation of the implementation of the OCSP responder. It's not a reason to ignore policy that is grounded in the very reasonable desire to ensure that the certificate's revoked status is known to any client which checks OCSP instead of CRL. -- Eric On Sat, Feb 2, 2019 at 4:31 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Personally I think it would be better, if the revoke reason "Certificate > hold" on the CRL would be allowed for TLS certificates, as this state would > exactly cover the described scenario. The OCSP responder could in such a > case reply with "bad" and deliver the reason "certificate hold". But I > fully understand that browser developers had a lot of issues with this > state, so it is still forbidden. > > With best regards, > Rufus Buschart > > Siemens AG > Information Technology > Human Resources > PKI / Trustcenter > GS IT HR 7 4 > Hugo-Junkers-Str. 9 > 90411 Nuernberg, Germany > Tel.: +49 1522 2894134 > mailto:rufus.busch...@siemens.com > www.twitter.com/siemens > > www.siemens.com/ingenuityforlife > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief > Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, > Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and > Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, > Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > > > -----Ursprüngliche Nachricht----- > > Von: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > Im Auftrag von Kurt Roeckx via dev-security-policy > > Gesendet: Freitag, 1. Februar 2019 23:38 > > An: Wayne Thayer <wtha...@mozilla.com> > > Cc: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > > Betreff: Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations > (KIR) > > > > On Fri, Feb 01, 2019 at 03:02:17PM -0700, Wayne Thayer wrote: > > > It was pointed out to me that the OCSP status of the misissued > > > certificate that is valid for over 5 years is still "unknown" despite > > > having been revoked a week ago. I asked KIR about this in the bug [1] > > > and am surprised by their response: > > > > > > This certificate is revoked on CRL. Because the certificate has been > > > never > > > > received by the customer its status on OCSP is "unknown". To make > > > > the certificate "revoked" on OCSP first we should make it "valid" > > > > what makes no sense. I know there is inconsistency between CRL and > > > > OCSP but there are some scenarios when it can be insecure to make it > > > > valid just in order to make it revoked. > > > > > > > > > > Upon further questioning KIR states: > > > > > > Of course I can mark it as revoked after I make it valid, but I think > > > it is > > > > more secure practice not to change its status at all when the > > > > certificate is not received by the customer. Let's suppose the > > > > scenario when your CA generate certificate and the customer wants > > > > you to deliver it to its office. What OCSP status the certificate > > > > should have when you are on your way to the customer office? valid - > > > > I do not think so. When the certificate is stolen you are in > > > > trouble. So the only option is "unknown" but then we have different > > > > statuses on CRL and OCSP - but we are still safe. It is not only my > opinion, we had a big discuss with our auditors about that. > > > > > > > > > > Does anyone other then KIR and their auditor (Ernst & Young) think > > > this is currently permitted? At the very least, I believe that > returning "unknown" > > > for a revoked certificate is misleading to Firefox users who will > > > receive the "SEC_ERROR_OCSP_UNKNOWN_CERT" error instead of > > > "SEC_ERROR_REVOKED_CERTIFICATE". > > > > > > Does anyone other than KIR and Ernst & Young believe that this meets > > > WebTrust for CAs control 6.8.12? [2] > > > > If you follow the RFC, the "unknown" answer can mean that it doesn't > know, and that an other option like a CRL can be tried. > > With "unknown", it doesn't say anything about being valid or not. > > > > I don't think that interpretation is very useful. I think that the OCSP > server should know about the certificate before the customer has > > the certificate. I think that if you have a properly signed certificate > within it's validity period, the OCSP should always return either > > "good" or "revoked", never "unknown". Once a certificate is generated > and it's not revoked it's valid. > > > > Would it be useful to have a requirement in the BRs that the OCSP server > should not answer with "unknown" for an issued certificate > > within it's validity period? > > > > > > Kurt > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
