Re: EJBCA performs incorrect calculation of validities
On 2020-10-28 20:54, Ryan Sleevi wrote: On Wed, Oct 28, 2020 at 10:50 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: This aspect of RFC5280 section 4.1.2.5 is quite unusual in computing, where the ends of intervals are typically encoded such that subtracting the interval ends (as pure numbers) yields the interval length. = notBefore, <= notAfter is as classic as "< size - 1" in 0-indexed for-loops (i.e. a size of 1 indicates there's one element - at index 0), or "last - first" needs to add +1 if counting elements in a pointer range. 0-indexed for-loops typically use "< size" or "<= size - 1", illustrating how hard it is to get such cases right. As a data point, the reference CA code in the OpenSSL library, version 1.1.0 Generates a whole bunch of completely invalid badness that is completely non-compliant, and is hardly a "reference" CA (c.f. the long time to switch to utf8only for DNs as just one of the basic examples) The "ca" "app" inside the openssl command line tool is officially defined as being "reference code only", not intended as an actual production CA implementation, although many people have found it useful as a component of low volume production CA implementations. This "reference" or "sample" code and its sample configuration contains comments as to what choices are compatible with older Mozilla code, including that using UTF-8 strings in DNs would cause older Mozilla code to fail. So this seems another detail where the old IETF working group made things unnecessarily complicated for everybody. https://www.youtube.com/watch?v=HMqZ2PPOLik https://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-new-part1-01.txt dated 2000. This is 2020. Where does that change come from? https://www.itu.int/rec/T-REC-X.509-23-S/en (aka ITU's X.509), which in 2000, stated "TA indicates the period of validity of the certificate, and consists of two dates, the first and last on which the certificate is valid." Does that mean this was a change in 2000? Nope. It's _always been there_, as far back as ITU-T's X.509 (11/88) - https://www.itu.int/rec/T-REC-X.509-198811-S/en ITU's X.509 (10/2012) doesn't seem to contain the sentence quoted and seems to be completely silent as to the inclusive/exclusive interpretation of the ends of the validity interval. And this doesn't seem to change in corrigendum 2 from 04/2016. It helps to do research before casting aspersions or proposing to reinterpret meanings that are older than some members here. The overarching problem is that some people love to do language lawyering with the exact meanings of specifications, and strictly enforcing every minute detail, such as the fact that RFC5280 from 2008 insists that these two ASN.1 fields should be interpreted as "inclusive", while 398 days and 1 second is technically more than 398 days. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: EJBCA performs incorrect calculation of validities
On Wed, Oct 28, 2020 at 10:50 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This aspect of RFC5280 section 4.1.2.5 is quite unusual in computing, > where the ends of intervals are typically encoded such that subtracting > the interval ends (as pure numbers) yields the interval length. > >= notBefore, <= notAfter is as classic as "< size - 1" in 0-indexed for-loops (i.e. a size of 1 indicates there's one element - at index 0), or "last - first" needs to add +1 if counting elements in a pointer range. > As a data point, the reference CA code in the OpenSSL library, > version 1.1.0 > Generates a whole bunch of completely invalid badness that is completely non-compliant, and is hardly a "reference" CA (c.f. the long time to switch to utf8only for DNs as just one of the basic examples) So this seems another detail where the old IETF working group made > things unnecessarily complicated for everybody. > https://www.youtube.com/watch?v=HMqZ2PPOLik https://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-new-part1-01.txt dated 2000. This is 2020. Where does that change come from? https://www.itu.int/rec/T-REC-X.509-23-S/en (aka ITU's X.509), which in 2000, stated "TA indicates the period of validity of the certificate, and consists of two dates, the first and last on which the certificate is valid." Does that mean this was a change in 2000? Nope. It's _always been there_, as far back as ITU-T's X.509 (11/88) - https://www.itu.int/rec/T-REC-X.509-198811-S/en It helps to do research before casting aspersions or proposing to reinterpret meanings that are older than some members here. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: EJBCA performs incorrect calculation of validities
On 2020-10-28 11:55, Mike Kushner wrote: Hi all, We were alerted to the fact that EJBCA does not calculate certificate and OCSP validities in accordance with RFC 5280, which has been a requirement since BR 1.7.1 The word "inclusive" was not caught, meaning that a certificate/response issued by EJBCA will have a validity of one second longer than intended by the RFC. This will only cause an incident for certificates of a validity of exactly 398 days - any certificates with shorter validities are still within the requirements. This has been fixed in the coming EJBCA 7.4.3, and all PrimeKey customers were alerted a week ago and recommended to review their certificate profiles and responder settings to be within thresholds. While investigating this we noticed that several non-EJBCA CAs seem to issue certificates with the same non RFC-compliant validity calculation (but still within the 398 day limit), so as a professional courtesy we wish like to alert other vendors to review their implementations and lessen the chance of any misissuance. Any response from the Mozilla NSS team as to the correct implementation of this detail in all related NSS code (including, but not limited to, the client side code interpreting the validity data in received certificates, OCSP responses etc.). This aspect of RFC5280 section 4.1.2.5 is quite unusual in computing, where the ends of intervals are typically encoded such that subtracting the interval ends (as pure numbers) yields the interval length. As a data point, the reference CA code in the OpenSSL library, version 1.1.0 also treats the "Not after" time as exclusive when generating certificates and the OpenSSL client code treats both timestamps as exclusive when validating certificates. So this seems another detail where the old IETF working group made things unnecessarily complicated for everybody. From a policy perspective, if enough code out there has the same interpretation as old EJBCA versions, maybe it would make more sense for the policy bodies to override RFC5280. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: EJBCA performs incorrect calculation of validities
Mike, How do you plan to stop similar issues from occurring in future? Thank you Burton On Wed, 28 Oct 2020, 10:55 Mike Kushner via dev-security-policy, < dev-security-policy@lists.mozilla.org> wrote: > Hi all, > > We were alerted to the fact that EJBCA does not calculate certificate and > OCSP validities in accordance with RFC 5280, which has been a requirement > since BR 1.7.1 The word "inclusive" was not caught, meaning that a > certificate/response issued by EJBCA will have a validity of one second > longer than intended by the RFC. > > This will only cause an incident for certificates of a validity of exactly > 398 days - any certificates with shorter validities are still within the > requirements. > > This has been fixed in the coming EJBCA 7.4.3, and all PrimeKey customers > were alerted a week ago and recommended to review their certificate > profiles and responder settings to be within thresholds. > > While investigating this we noticed that several non-EJBCA CAs seem to > issue certificates with the same non RFC-compliant validity calculation > (but still within the 398 day limit), so as a professional courtesy we wish > like to alert other vendors to review their implementations and lessen the > chance of any misissuance. > > Cheers, > Mike Agrenius Kushner > Product Owner, EJBCA > ___ > 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
EJBCA performs incorrect calculation of validities
Hi all, We were alerted to the fact that EJBCA does not calculate certificate and OCSP validities in accordance with RFC 5280, which has been a requirement since BR 1.7.1 The word "inclusive" was not caught, meaning that a certificate/response issued by EJBCA will have a validity of one second longer than intended by the RFC. This will only cause an incident for certificates of a validity of exactly 398 days - any certificates with shorter validities are still within the requirements. This has been fixed in the coming EJBCA 7.4.3, and all PrimeKey customers were alerted a week ago and recommended to review their certificate profiles and responder settings to be within thresholds. While investigating this we noticed that several non-EJBCA CAs seem to issue certificates with the same non RFC-compliant validity calculation (but still within the 398 day limit), so as a professional courtesy we wish like to alert other vendors to review their implementations and lessen the chance of any misissuance. Cheers, Mike Agrenius Kushner Product Owner, EJBCA ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
