EJBCA performs incorrect calculation of validities

[Mike Kushner]

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

[Burton]

Mike,

How do you plan to stop similar issues from occurring in future?

Thank you

Burton

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Jakob Bohm]

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

[Ryan Sleevi]

On Wed, Oct 28, 2020 at 10:50 AM Jakob Bohm via dev-security-policy <
dev-secur...@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-200003-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.

[Jakob Bohm]

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-secur...@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-200003-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.