Re: OCSP responder support for SHA256 issuer identifier info
This prompted me to dig up more information of this old issue. Here is the issue in our tracker: https://jira.primekey.se/browse/ECA-3149 Looking back in my records it's not only a local jurisdiction auditor that enforced SHA-256. We also received several request from Web PKI CAs to implement SHA256 support in CertID. Some sparked by the mozilla issue to accept SHA256 based CertID in responses. https://bugzilla.mozilla.org/show_bug.cgi?id=663315 There was a discussion on the RFC compliance back then, noting the differences between RFC6960 and 5019. RFC5019 is from 2007 though, and we are no strangers here to extending old RFCs. I think it is a valid, deliberate, violation of RFC5019 to support new algorithms. It is a fact that when supplying to many different jurisdictions, private PKIs as well as Web PKI. SHA-256 must be supported. The current approach has worked flawless since 2014, and I think it's a reasonable approach. I agree with Curt that #1 is correct in a generic perspective, but #4 is also valid and compliant with RFC509 2.2.3. Even #5 as well. Standardizing clients on SHA-1 is fine, as RFC5019 says. Servers should be allowed to support SHA-256 (or other algorithms) to not complicate configuration and infrastructure even further. On Friday, October 4, 2019 at 8:38:41 PM UTC+2, Jeremy Rowley wrote: > (And, for the record, none of that legacy infrastructure that would Ryan > mentions taking years to update exists anymore. Yay for shutting down legacy > systems!) > > -Original Message- > From: dev-security-policy On > Behalf Of Jeremy Rowley via dev-security-policy > Sent: Friday, October 4, 2019 12:35 PM > To: Tomas Gustavsson ; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: RE: OCSP responder support for SHA256 issuer identifier info > > The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC > 6960. The requirements do not specific which RFC to follow when processing > requests, but I think you can imply that either one is required, right? > > Section 2.1.1. specifies that: > Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash > and the CertID.issuerKeyHash values. Anyone implementing the BRs would expect > SHA1 for both fields. Where does the requirement to support SHA256 come in? > As Ryan mentioned, there was some discussion, but it seems like there was > nothing settled. I'd support a ballot clarifying the profile, but I don't > understand the value of requiring both SHA1 and SHA2 signatures for OCSP. > Doesn't it just make OCSP more cumbersome? > > -Original Message- > From: dev-security-policy On > Behalf Of Tomas Gustavsson via dev-security-policy > Sent: Friday, October 4, 2019 1:45 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: OCSP responder support for SHA256 issuer identifier info > > I was pointed to this interesting discussion. We were forced to support > requests with SHA256 in CertID back in 2014. Not for any relevant security > reasons, just because some stubborn auditors saw a red flag on the mentioning > of SHA-1. > > We've implemented it by having both hashes in the lookup table where we check > for issuer when a response comes in. > > What to have in the response was an interesting topic. > > In the response we use the same certID that the client sent. I would expect > that any client if checking CertID in the response would expect it to match > what they send. > > I'm suspicious of adding two SingleResponse in the response, one for each > CertID. > - Clients are used to one response, they may fail verification if the first > one doesn't have the same CertID > - When auditors that requiring SHA3, shall we add three? That approach does > not seem agile. > - It increases the size of responses, we've been told before about the desire > to keep responses as small as possible (typically to fit in a single etehrnet > frame) > > Regards, > Tomas > > On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote: > > Thanks for raising this! > > > > There some some slight past discussion in the CA/B Forum on this - > > https://cabforum.org/pipermail/public/2013-November/002440.html - as > > well as a little during the SHA-1 deprecation discussions ( > > https://cabforum.org/pipermail/public/2016-November/008979.html ) and > > crypto agility discussions ( > > https://cabforum.org/pipermail/public/2014-September/003921.html ), > > but none really nailed it down to the level you have. > > > > Broadly, it suggests the need for a much tighter profile of OCSP, > > either within policies or the BRs. Two years ago, I started work on > > such a thing - > &g
Re: OCSP responder support for SHA256 issuer identifier info
I was pointed to this interesting discussion. We were forced to support requests with SHA256 in CertID back in 2014. Not for any relevant security reasons, just because some stubborn auditors saw a red flag on the mentioning of SHA-1. We've implemented it by having both hashes in the lookup table where we check for issuer when a response comes in. What to have in the response was an interesting topic. In the response we use the same certID that the client sent. I would expect that any client if checking CertID in the response would expect it to match what they send. I'm suspicious of adding two SingleResponse in the response, one for each CertID. - Clients are used to one response, they may fail verification if the first one doesn't have the same CertID - When auditors that requiring SHA3, shall we add three? That approach does not seem agile. - It increases the size of responses, we've been told before about the desire to keep responses as small as possible (typically to fit in a single etehrnet frame) Regards, Tomas On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote: > Thanks for raising this! > > There some some slight past discussion in the CA/B Forum on this - > https://cabforum.org/pipermail/public/2013-November/002440.html - as well > as a little during the SHA-1 deprecation discussions ( > https://cabforum.org/pipermail/public/2016-November/008979.html ) and > crypto agility discussions ( > https://cabforum.org/pipermail/public/2014-September/003921.html ), but > none really nailed it down to the level you have. > > Broadly, it suggests the need for a much tighter profile of OCSP, either > within policies or the BRs. Two years ago, I started work on such a thing - > https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large CA > suggested it would take them years to even implement that, and it wouldn't > have covered this! > > I can't see #3 being valid, but I can see and understand good arguments for > #1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960. > > The question about whether #2 is valid is about whether or not a client > should be expected to be able to match the CertID in the > OCSPRequest.requestList to the CertID in the > OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that the > response MUST include a SingleResponse for each certificate in the request, > but may include additional, and so a client encountering a SHA-1 computed > CertID in response to a SHA-256 CertID would have to recompute all the > CertIDs to see if it matched. On the other hand, RFC 5019 2.2.1 states that > "In the case where a responder does not have the ability to respond to an > OCSP response containing an option not supported by the server, it SHOULD > return the most complete response it can." > > A different question would be whether said responder, in response to a > SHA-1 request, can and/or should provide a response with both a SHA-1 > computed CertID AND a SHA-256 computed CertID. This would improve the > pre-generation performance that Rob was concerned about, and allow both > SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse. > > However, one concern with the pre-generation approach is that 4.2.2.3 > requires that the response MUST include a SingleResponse for each > certificate in the request. RFC 5019 2.1.1 limits clients using that > profile to only include one Request in the OCSPRequest.RequestList (via a > MUST). So should responders be permitted to reject requests that include > multiple? Or should they be required to do online signing? Similar to > extensions. > > This suggests we should actually nail down and define what we expect, > perhaps as a clear processing algorithm for how a Responder must respond to > various requests. I suspect that "What we want" is a profile of RFC 5019 > that nails down the SHOULD / SHOULD NOT and MAY / MAY NOT behaviours from > 5019, as relevant to the Web PKI, and describe a processing algorithm that > can be used to both assess compliance and test implementation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On Friday, August 30, 2019 at 8:58:17 PM UTC+2, Ryan Sleevi wrote: > On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy < > Despite all of the writing above, I'm too lazy to copy/paste my comment > from the Let's Encrypt issue, but I would hope any CA contemplating things > should look at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652#c3 in > terms of a possible 'ideal' flow, and to share concerns or considerations > with that. Even better would be CAs that have suggestions on how best to > codify and memorialize that suggestion, if it's sensible and correct. I added a comment to the bugzilla. I think there are several ways the process can be made safe, depending on the way a CA operates and which technologies are used. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On Saturday, August 31, 2019 at 5:07:48 PM UTC+2, Jeremy Rowley wrote: > Obviously I think good is the best answer based on my previous posts. A > precert is still a cert. But I can see how people could disagree with me. I don't see anything fundamentally wrong with either approach. Since BR 4.9.10 has a four day update window it would typically, within the BR limits, only be an internal exercise for the CA. BR 4.9.10: "For the status of Subscriber Certificates: The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days." > > From: dev-security-policy on > behalf of Jeremy Rowley via dev-security-policy > > Sent: Saturday, August 31, 2019 9:05:24 AM > To: Tomas Gustavsson ; > mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” > for Some Precertificates > > I dont recall the cab forum ever contemplating or discussing ocsp for > precertificates. The requirement to provide responses is pretty clear, but > what that response should be is a little confusing imo. > ____ > From: dev-security-policy on > behalf of Tomas Gustavsson via dev-security-policy > > Sent: Saturday, August 31, 2019 9:00:08 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” > for Some Precertificates > > On Saturday, August 31, 2019 at 3:13:00 PM UTC+2, Jeremy Rowley wrote: > > >From RFC6962: > > > > “As above, the Precertificate submission MUST be accompanied by the > > Precertificate Signing Certificate, if used, and all additional > > certificates required to verify the chain up to an accepted root > > certificate. The signature on the TBSCertificate indicates the certificate > > authority's intent to issue a certificate. This intent is considered > > binding (i.e., misissuance of the Precertificate is considered equal to > > misissuance of the final certificate). Each log verifies the > > Precertificate signature chain and issues a Signed Certificate Timestamp on > > the corresponding TBSCertificate.” > > > > >From 7.1.2.5 of the baseline requirements: > > “For purposes of clarification, a Precertificate, as described in RFC 6962 > > – Certificate Transparency, shall not be considered to be a “certificate” > > subject to the requirements of RFC 5280 - Internet X.509 Public Key > > Infrastructure Certificate and Certificate Revocation List (CRL) Profile > > under these Baseline Requirements” > > > > >From 6960: > >The "good" state indicates a positive response to the status inquiry. > > At a minimum, this positive response indicates that no certificate with the > > requested certificate serial number currently within its validity interval > > is revoked. This state does not necessarily mean that the certificate was > > ever issued or that the time at which the response was produced is within > > the certificate's validity interval. Response extensions may be used to > > convey additional information on assertions made by the responder regarding > > the status of the certificate, such as a positive statement about issuance, > > validity, etc. > > > >The "revoked" state indicates that the certificate has been revoked, > > either temporarily (the revocation reason is certificateHold) or > > permanently. This state MAY also be returned if the associated CA has no > > record of ever having issued a certificate with the certificate serial > > number in the request, using any current or previous issuing key (referred > > to as a "non-issued" certificate in this document). > > > >The "unknown" state indicates that the responder doesn't know about the > > certificate being requested, usually because the request indicates an > > unrecognized issuer that is not served by this responder.” > > > > Mozilla Policy: > > > > 1. Does not define a precertificate. Instead Mozilla policy covers > > everything with serverAuth (1.1) > > > > 2. Requires functioning OCSP if the certificate contains an AIA (5.2) > > > > 3. Must provide revocation information via the AIA for the cert (6) > > > > Argument for responding “Good”: > > A pre-certificate is a certificate and contains an AIA. Per the Mozilla > > policy, the CA must provide services. Providing revoked or unknown is > > incorrect because the pre-cert did issue. Although the BRs define the > > pre-
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On Saturday, August 31, 2019 at 3:13:00 PM UTC+2, Jeremy Rowley wrote: > >From RFC6962: > > “As above, the Precertificate submission MUST be accompanied by the > Precertificate Signing Certificate, if used, and all additional certificates > required to verify the chain up to an accepted root certificate. The > signature on the TBSCertificate indicates the certificate authority's intent > to issue a certificate. This intent is considered binding (i.e., misissuance > of the Precertificate is considered equal to misissuance of the final > certificate). Each log verifies the Precertificate signature chain and > issues a Signed Certificate Timestamp on the corresponding TBSCertificate.” > > >From 7.1.2.5 of the baseline requirements: > “For purposes of clarification, a Precertificate, as described in RFC 6962 – > Certificate Transparency, shall not be considered to be a “certificate” > subject to the requirements of RFC 5280 - Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation List (CRL) Profile > under these Baseline Requirements” > > >From 6960: >The "good" state indicates a positive response to the status inquiry. At > a minimum, this positive response indicates that no certificate with the > requested certificate serial number currently within its validity interval is > revoked. This state does not necessarily mean that the certificate was ever > issued or that the time at which the response was produced is within the > certificate's validity interval. Response extensions may be used to convey > additional information on assertions made by the responder regarding the > status of the certificate, such as a positive statement about issuance, > validity, etc. > >The "revoked" state indicates that the certificate has been revoked, > either temporarily (the revocation reason is certificateHold) or permanently. > This state MAY also be returned if the associated CA has no record of ever > having issued a certificate with the certificate serial number in the > request, using any current or previous issuing key (referred to as a > "non-issued" certificate in this document). > >The "unknown" state indicates that the responder doesn't know about the > certificate being requested, usually because the request indicates an > unrecognized issuer that is not served by this responder.” > > Mozilla Policy: > > 1. Does not define a precertificate. Instead Mozilla policy covers > everything with serverAuth (1.1) > > 2. Requires functioning OCSP if the certificate contains an AIA (5.2) > > 3. Must provide revocation information via the AIA for the cert (6) > > Argument for responding “Good”: > A pre-certificate is a certificate and contains an AIA. Per the Mozilla > policy, the CA must provide services. Providing revoked or unknown is > incorrect because the pre-cert did issue. Although the BRs define the > pre-cert as out of scope of the BRs for CRLs and 5280, that just means the > serial number can repeat. Responding anything other than good would provide > wrong information about the status of the pre-cert. > > Argument for responding “Revoked”, “Unknown”, or “Invalid”: > A pre-certificate is not a cert. The BRs define it as a not a cert as does > RFC 6962. A pre-cert is an intent to issue a certificate. RFC6960 > specifically calls out that the CA may use revoke as a response for > certificates without a record of being issued and unknown where there isn’t a > status yet. Although the Mozilla policy is silent on the status of whether a > pre-cert is a certificate, section 2.3 incorporates the baseline > requirements. As such, the Mozilla policy implicitly defines a precertificate > as “not a certificate”. Because it’s not a certificate the OCSP service does > not know how to respond so any response is okay because there is no > certificate with that serial number until the ‘intent to issue’ is fulfilled. > > Note that even if you argue that “revoked”, “invalid”, or “unknown” are > appropriate, the RFC still permits “good” as a response because no > certificates with that serial number are revoked. Good is the safe answer. Was there not a plan in CABF on allowing unathorized for "unknown" responses to save on private key usage? (I'm unable to find it now) > > > From: dev-security-policy on > behalf of Tomas Gustavsson via dev-security-policy > > Sent: Saturday, August 31, 2019 5:01:42 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” > for Some Precertificates > > Hi, > > I
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
Hi, I find and hear a few non conclusive, sometimes contradictory, messages about OCSP responder handling of pre-certificates without final certificates. Reading this thread I don't find a firm conclusion either (albeit I may have missed it). I'm not saying anything others have not said before, so I don't claim to say anything new, just to summarize what I believe to be a safe behavior. (I'm merely interested in the technical behavior of an OCSP responder) My position dates back to 2013 during CT implementation. Discussions back then: https://groups.google.com/forum/m/#!searchin/certificate-transparency/tomas/certificate-transparency/1tWzSXKe3gQ "a Precertificate is arguably not a Certificate". as well as: "The precertificate contains a critical extension that no verifier should understand, and therefore will not verify." In combination with RFC6960 (introduction): "The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of identified certificates." and Ballot 80: https://cabforum.org/2012/08/02/ballot-80-response-for-non-issued-certificates/ For an OCSP server a query is neither for a "pre certificate" nor a "certificate", the OCSP responder just sees an issuer (hash) and a serial number. It's a query for revocation status about the issuer and serial number pair passed in the request. >From this my conclusion was, and still is: - A pre certificate is not an issued certificate in the Web PKI. As such an OCSP responder should answer "anything but good" for this issuer/serialnumber combination if a "real" certificate has not been (yet) issued. >From a RP perspective, any RP that queries OCSP during an attempt, with >intent, to use a pre certificate (with poison extension) is broken and the >only safe goal is to try to prevent this RP from using the pre certificate. >Again my conclusion is that the safe way is to answer "anything but good". For OCSP there are at least two corner cases here: 1. A pre certificate has been issued, but the real certificate has not and never will be 2. There is a time gap period between the issuance of the pre certificate and the real certificate For 1, the "intended to be issued" certificate should be revoked asap in any case, so "anything but good" is the proper answer. For 2, there is a short period where someone monitoring log servers may discover the pre certificate and poison any OCSP response cache by querying for this issuer/serial (getting a "anything but good" for the not yet issued real certificate). After cache expiry the response will be good. The same can happen by shotgunning the OCSP responder with random serials, albeit it's hard to hit a "real" upcoming serial number in the >64bit random serial number space, or if there is a delay between releasing the real certificate and fully distributing it to OCSP responders. When direct updates to OCSP is used this periods is measured in seconds maximum, and milliseconds optimally. Making a long story short: - I belive answering "anything but good" is a proper answer for pre certificates (issuer/serialno) where no real certificate was issued or distributed. Did I miss anything? Regards, Tomas ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Open Source CA Software
Hi, It might have been found, but there's a good chance it would have been bypassed anyhow. Since it was not a bug in the code, you would have to had analyzed it in the context of the discussions around b164, which I think there are probably very few people who could/would. I may be wrong, and we surely appreciate the more eyes on EJBCA the better. We love issue reports from the Community. My take is that this was a bit of pure chance at play here. As EJBCA had used 8 octets serial numbers (64 bits) as default since 2001, and by coincidence CAB Forum chose exactly the same number, 64 bits (note that I speak only about the number itself here, not about the meaning). Simply by the similarity of those numbers it was overlooked that dragons were lurking. If CAB Forum had chosen 56, 72, 96 or any other random number, nobody would have missed it and compliant configurations would have been made. Generally, as you know, EJBCA has a wide array of use cases where CAB Forum is one important, but must remain configurable (down to 4 octets serials as example). An important user base as CAB Forum deserves compliant defaults of course, which has now been addressed by Mike and his team. Here's hoping for more code reviews! Cheers, Tomas On Friday, March 15, 2019 at 12:35:53 AM UTC+1, James Burton wrote: > (Forgot to post it to m.d.s.p) > > Your right that we all failed to conduct the proper due diligence source > code checks on EJBCA and therefore missed this important issue. We all need > to learn from this past mistake and implement better checks which prevents > issues like this that might arise in the future. > > Thank you, > > Burton > > On Thu, Mar 14, 2019 at 10:57 PM Ryan Sleevi wrote: > > > > > > > On Thu, Mar 14, 2019 at 6:54 PM James Burton via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> Let's Encrypt CA software 'Boulder' is open source for everyone to browse > >> and check for issues. All other CAs should follow the Let's Encrypt lead > >> and open source their own CA software for everyone to browse and check for > >> issues. We might have found the serial number issue sooner. > >> > > > > Considering EJBCA is open-source, this does not seem that it would > > logically follow. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: EJBCA defaulting to 63 bit serial numbers
Hi, As others have already pointed out the subject in this thread is incorrect. There are no, and has never been any, 63 bit serial numbers created by EJBCA. As the specific topic has already been discussed, I just wanted to reference to the post[1] with technical details, if anyone ends up in this thread without background. Regards, Tomas [1] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/nnLVNfqgz7g%5B26-50%5D ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
