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-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.
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
