DigiCert OCSP services returns 1 byte
Hello, I created the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 ___ 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
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
Re: DigiCert OCSP services returns 1 byte
This is a great discussion and I want to thank everyone for their continued input. Let me try and summarize my interpretation based on the input from this thread and related RFC. My interpretation is an “unknown” OCSP response should be used in the following conditions: 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder is NOT authoritative (wrong issuing CA). 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative (correct issuing CA) but for whatever reason the OCSP responder does not know the status of the requested certificates and ONLY if the certificate for which the status is requested contains another OCSP responder URL available in the AIA extension. My interpretation is a “revoked” OCSP response should be used in the following conditions: 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the requested certificate has been revoked. 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the CA corresponding to the issuerNameHash and issuerKeyHash has been revoked. 3. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the requested certificate has not been issued. This OCSP response MUST include the extended revoked definition response extension in the response, indicating that the OCSP responder supports the extended definition of the "revoked" state to also cover non-issued certificates. The SingleResponse related to this non-issued certificate MUST specify the revocation reason certificateHold (6), MUST specify the revocationTime January 1, 1970, and MUST NOT include a CRL references extension or any CRL entry extensions. [1] I agree number 3 above is in conflict with the BRs as pointed out by Wayne. - Curt [1] RFC 6960: https://tools.ietf.org/html/rfc6960 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OCSP responder support for SHA256 issuer identifier info
I am looking at this from an interoperability perspective and not security. If a client is requesting a SHA256 hash for the issuerNameHash and issuerKeyHash I don’t think the OCSP responder should be prohibited from returning a response containing issuerNameHash and issuerKeyHash using SHA256. I like the idea of agility for algorithms and it appears the RFCs supports this by having a CertID.hashAlgorithm field. - Curt > On Sep 19, 2019, at 4:24 AM, Rob Stradling via dev-security-policy > wrote: > > I'm not aware of any requirement that demands that OCSP responders > support SHA-256 for CertID.hashAlgorithm or of any requirement that > forbids this. Therefore, I think 1, 2 and 4 are all acceptable > responses to an OCSP request whose CertID.hashAlgorithm is SHA-256. > > SHA-1 is the defacto requirement for CertID.hashAlgorithm, and I would > (still [1]) prefer to see SHA-1 required and all other hash algorithms > forbidden. > > Supporting stronger hash algorithms for CertID.hashAlgorithm would not > lead to any security gain, but it would inflict pain on those CAs that > need to regularly pregenerate OCSP responses (see [2]) for all unexpired > leaf certificates. > > > [1] https://cabforum.org/pipermail/public/2013-November/002453.html > <https://cabforum.org/pipermail/public/2013-November/002453.html> > > [2] https://tools.ietf.org/html/rfc6960#section-4.4.7.2.2 > <https://tools.ietf.org/html/rfc6960#section-4.4.7.2.2> > > On 19/09/2019 01:09, Curt Spann via dev-security-policy wrote: >> 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 > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > <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
Re: DigiCert OCSP services returns 1 byte
Great feedback. This is exactly the type of input needed to get clarity around
operating OCSP responder services for certificates in the WebPKI ecosystem.
> I think an important part missing from this, overall, is to highlight that
> these clauses only apply with respect to definitive responses. That is, this
> only applies to the set of responses for which a pre-certificate exists (and
> thus a matching certificate is presumed to exist) or for where a certificate
> actually exists.
Agreed, these clauses need to apply to definitive responses (pre-cert || cert).
> Presuming the OCSP responder supports the requestor CertID algorithm :)
Correct.
> I'm not sure I understand where the "ONLY" clause comes from? 6960 and 5280
> both presuppose the existence of other sources of revocation, beyond those
> enumerated within the AIA. For 6960, Section 2.2 leaves this a bit up in the
> air. So I don't think either the policies or text currently require this
> "ONLY" clause, but I do think we want to nail down the situations here. As it
> relates specifically to the (precert || cert) case, the BRs treat the
> responder as a singular "the", so I don't think the ONLY applies... so I
> think this whole thing washes out as "not allowed" for the case of (precert
> || cert), and is met by "unauthorized", as well as possible transport-layer
> options (RFC 5019 is somewhat silent, AFAICT, on this)
My interpretation incorrectly presumed only OCSP as an option. I was attempting
to address the NOTE in RFC 6960 from Section 2.2 but I failed to account for
CRLs:
NOTE: The "revoked" status indicates that a certificate with the
requested serial number should be rejected, while the "unknown"
status indicates that the status could not be determined by
this responder, thereby allowing the client to decide whether
it wants to try another source of status information (such as a
CRL).
> Agreed, with a caveat. This is a MAY derived from Section 2.7, and so I
> wasn't sure if the suggestion was enumerating it as a MUST ("should be used")
> or merely acknowledging it as a valid situation for revoked.
I was acknowledging it as a valid situation for revoked and did pull from
Section 2.7.
> If the assumption of policy is that the existence of a pre-certificate is
> proof of equivalent issuance, then the only situation this arises is if and
> only if the CA is running an online signing service in line with 6960, rather
> than the pre-distribution approach of RFC 5019 that the scale of the Web PKI
> effectively ensures is necessary, and only in the cases where a
> pre-certificate /doesn't/ exist.
I must admit I was focused on RFC 6960 and should have been including RFC 5019
in my interpretation.
> So to recap:
> - In RFC 5019, it's clear that one of the core goals of 5019 is to not
> require the creation of definitive responses for the entire serial space. So
> we're only talking (pre-cert || cert) definitive cases.
> - In RFC 6960, it's clear that one of the core goals of the extended response
> is to leave it /optional/ (MAY) for CAs to respond Revoked, and for serial
> numbers they have no record of having issued. So we're talking !(pre-cert ||
> cert) cases.
Well said.
- Curt
___
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
> The CRL question is not about it being a requirement, but rather the fact > that it could / would lead to disparate treatment between CRL and OCSP for > the same certificate, which does not feel right. The CRL would only grow if the (pre-cert || cert) needed to be revoke for any reason. CRLs only contain a list of revoked (pre-cert || cert) and don’t attempt to address whether the (pre-cert || cert) has been issued. - Curt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
