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
