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
Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)
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] - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523186 [2] http://www.webtrust.org/principles-and-criteria/docs/item85228.pdf On Tue, Jan 29, 2019 at 2:10 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2019-01-29 1:29, Wayne Thayer wrote: > > Piotr just filed an incident report on the misissuance that was reported > on > > 18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186 > > I guess this part is not very clear to me: > > > We identified and removed from system the registration policy that > > issued the problematic certificate. The problematic policy template > > was not listed in policies allowed for Certificate Transparency > > logging but contained Signed Certificate Timestamp extension. The > > usage of such policy template should be blocked by the CT > > functionality. We had only one policy in such state. > > I could read that as: > 1) This certificate was not supposed to be logged in CT > 2) The issuing should have been prevented > > I assume 2) was meant. > > > 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
