On 09/07/2018 03:31, Peter Gutmann wrote:
Ryan Sleevi <r...@sleevi.com> writes:
Is that because you believe it forbidden by spec, or simply unwise?
The spec allows almost anything, and in particular because there isn't any one
definitive "spec" you can have ten incompatible interpretations that are all
compliant to something that can claim to be the spec (see the Style Guide
description).
However, the chances of anything displaying this stuff correctly is
essentially zero.
The value of a linter is fairly proportional to its value in spec adherence.
Which of the half-dozen to dozen interpretations of what constitutes "the
spec" do you want it to enforce, and why that particular one and not the
others?
The SPEC obviously is X.690(2015) clause 8.23, most notably Table 3, and
the ISO standards therein referenced (ISO 2022 and ISO 2375). Note that
clause 8.23.5.1 (via X.680(2015) Table 8) seems to further restrict the
escape codes to those that select one of the character sets "6, 87, 102,
103, 106, 107, 126, 144, 150, 153, 156, 164, 165, 168 + SPACE + DELETE"
(See also Note 2 to X.680(2015) Table 8 about character set 6 versus
102).
For TLS capable certificates, the additional restrictions in the latest
CAB/F BRs, and the therein referenced parts of the PKIX RFCs further
restrict what is allowed.
For e-mail or IPsec certificates, there are no common standards
currently in place, and since the linter is not Mozilla specific it
cannot assume any Mozilla policies for such certificates. IPsec is
notable because the authors of RFC4945 added a strong recommendation
that IPsec certificates do not specify extended key usage.
For Code signing certificates (not Mozilla relevant, but relevant for
CAB/F BR compliance), the CAB/F BRs for such certificates further
restrict the certificate contents.
Also, if it knows that the chances of anything being able to correctly handle
a particular string form is essentially zero, even if some interpretation of
the spec can claim it's OK, shouldn't it warn?
Therefore, any use of permitted ISO 2022 escape sequences in
TeletexString should still generate a warning. As should strings
containing the DELETE character. Spaces however are permitted in many
elements, for example O,L,ST,street and a non-address CN.
making them errors puts burden on CAs and the community to evaluate whether
or not it's an "actual violation" or just something "monumentally stupid"
No, it's a way of telling CAs that if they do this, things will break. That's
exactly what the original lint did, "this is permitted in the spec but you
probably weren't intending to do that". It's cert*lint*, not
certstrictcompliancecheckertoarbitraryunworkablerules.
Peter.
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
