openssl
openssl copied to clipboard
openssl
Increase size limits of RFC values
CLA: trivial
Leading edge technologies are using long names to define for example a fully qualified domain name. Thus, it is of utmost importance to replace those old limits and adapt them to the current needs.
Also max values have been defined in openssl.cnf file to prevent the binary of openssl from exiting and to provide the user with proper feedback in order to fix their input without the need of restarting the execution of the binary.
Checklist
- [X] documentation is added or updated
I have not found out an authoritative source, thus values should be discussed prior of this PR's possible merge. However, current limits can not support examples of values such as ' console-openshift-console.randomuser-cluster-0c576f1a70d454f092d8591887631748-0000.eu-de.containers.appdomain.cloud ' and similar lengthy FQDNs.
One might just as well ask if we have an authoritative source for the current values ... which is seems that we may. E.g., RFC 5280's appendix A.1, that lists:
-- specifications of Upper Bounds MUST be regarded as mandatory
-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
-- Upper Bounds
-- Upper Bounds
ub-name INTEGER ::= 32768
ub-common-name INTEGER ::= 64
ub-locality-name INTEGER ::= 128
ub-state-name INTEGER ::= 128
ub-organization-name INTEGER ::= 64
ub-organizational-unit-name INTEGER ::= 64
[...]
ub-emailaddress-length INTEGER ::= 255
ub-common-name-length INTEGER ::= 64
ub-country-name-alpha-length INTEGER ::= 2
ub-country-name-numeric-length INTEGER ::= 3
[...]
ub-given-name-length INTEGER ::= 16
[...]
ub-organization-name-length INTEGER ::= 64
ub-organizational-unit-name-length INTEGER ::= 32
In my opinion this is wrong and we should not ignore the limits from RFC. The FQDN does NOT have to be in CN as the FQDN should be in Subject Alt Names as DNS name instead - there should be no limit for that.
OTC: Should we ignore limits from RFC 5280's appendix A.1?
No until there is any other authority established new widely used limits.
In my opinion this is wrong and we should not ignore the limits from RFC. The FQDN does NOT have to be in CN as the FQDN should be in Subject Alt Names as DNS name instead - there should be no limit for that.
Actually, RFC 5280 uses stronger words on the subject. From RFC 5280, 4.2.1.6. Subject Alternative Name (italics mine, for emphasis):
Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, MAY be included. Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4.
OTC: Unless there is a relevant authoritative source that overrides the RFC 5280 limits we aren't going to change the limits.