Re: DigiCert OCSP services returns 1 byte
Thanks Curt. Reading between the lines of Ryan's and your response, I'm thinking that we should specifically ban or limit the scope of "unknown" responses somewhere - perhaps in the BRs. Otherwise I think RFC 6960 leaves some room for a CA to argue that they are permitted to use that response in situations such as the one you described. On Wed, Sep 18, 2019 at 3:48 PM Curt Spann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > My interpretation is once a precertificate has been signed with the > issuing CA key the corresponding OCSP service should only respond with > "good" or "revoked". In this case an "unknown" response indicates the > specific serial number for the issuing CA has not been assigned which isn’t > the case. Since the serial number has been assigned the OCSP responder > should know about the status of that serial number for the issuing CA. If > there are no issues with the precertificate that would require its > revocation the OCSP responder should respond with “good”. If the > precertificate is classified as a misissuance (or any other reason that > would require revocation) the OCSP responder should respond with “revoked”. > > - Curt > ___ > 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
OCSP responder support for SHA256 issuer identifier info
In the WebPKI ecosystem I have seen a wide range of OCSP responses for OCSP requests using SHA256 for the issuerNameHash and issuerKeyHash. I have observed the following types of OCSP responses: 1. “good” response with issuerNameHash and issuerKeyHash using SHA256 2. “good” response with issuerNameHash and issuerKeyHash using SHA1 3. “unknown” response containing the correct SHA256 issuerNameHash and issuerKeyHash but signed with an incorrect OCSP signing cert (chains to different authority) 4. “unauthorized” response 5. “malformedrequest” response I would like to have a discussion with the community about what is thought to be the correct response. Of the various responses I have observed I think the correct response is number 1. I would also like to know if others have seen other variants of OCSP responses for request using SHA256 for the issuerNameHash and issuerKeyHash. Supporting info RFC 6960: https://tools.ietf.org/html/rfc6960 - 4.1.1. ASN.1 Specification of the OCSP Request RFC 2560: https://tools.ietf.org/html/rfc2560 - 4.1.1 Request Syntax - Curt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CCADB Policy Update: Exceptions to Policies, Practices, and Audit Information
When Rob Stradling announced the excellent addition of the "inconsistent Audit details" and Inconsistent CP/CPS Details" sections to the crt.sh Mozilla CA Certificate Disclosures report [1], we discovered some inconsistencies between Mozilla's expectations and CCADB policy [2]. To correct this, the following list of exceptions to providing audit information *for intermediate certs* has been added to the policy: - The SHA-256 fingerprint of the certificate is specifically listed as in scope in the audit statements of the parent certificate, and the “Audits Same as Parent” checkbox is checked; or - The certificate has expired; or - The certificate is technically-constrained as described in section 7.1.5 of the CA/Browser Forum Baseline Requirements, or - The certificate has been revoked, and the corresponding record in the CCADB has been updated with the correct revocation status. This change is captured in CCADB policy issues #30 [3] and #31 [4]. - Wayne [1] https://crt.sh/mozilla-disclosures [2] https://www.ccadb.org/policy#5-policies-practices-and-audit-information [3] https://github.com/mozilla/www.ccadb.org/issues/30 [4] https://github.com/mozilla/www.ccadb.org/issues/31 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert OCSP services returns 1 byte
My interpretation is once a precertificate has been signed with the issuing CA key the corresponding OCSP service should only respond with "good" or "revoked". In this case an "unknown" response indicates the specific serial number for the issuing CA has not been assigned which isn’t the case. Since the serial number has been assigned the OCSP responder should know about the status of that serial number for the issuing CA. If there are no issues with the precertificate that would require its revocation the OCSP responder should respond with “good”. If the precertificate is classified as a misissuance (or any other reason that would require revocation) the OCSP responder should respond with “revoked”. - Curt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
