ZLint v3.4.0-rc1
19 views
Skip to first unread message
chris
Sep 18, 2022, 3:08:19 PM9/18/22
to ZLint Announcements
# ZLint v3.4.0-rc1
The ZMap team is happy to share ZLint v3.4.0-rc1 (https://github.com/zmap/zlint/releases/tag/v3.4.0-rc1)
Thank you to everyone who contributes to ZLint!
## Breaking Changes:
No breaking changes were made in this release.
## New Features:
Individual lints may now be (optionally) configurable!
### For Lint Authors
For lint authors, please see [CONTRIBUTING.md](https://github.com/zmap/zlint/blob/master/CONTRIBUTING.md#making-your-lint-configurable) for more details on how to write a lint that may receive optional configurations.
### For users
For users of the CLI tool, configuring a particular lint is as simple as providing a valid `toml` file to ZLint.
`zlint -config configFile.toml mycert.pem`
ZLint also provides a facility for getting a print out of a valid, all default, configuration file such that users do not have to hunt through documentation to discover what lints are configurable and what their fields are.
For example...
`zlint -exampleConfig`
...currently prints to the terminal....
```toml
[AppleRootStorePolicyConfig]
[CABFBaselineRequirementsConfig]
[CABFEVGuidelinesConfig]
[CommunityConfig]
[MozillaRootStorePolicyConfig]
[RFC5280Config]
[RFC5480Config]
[RFC5891Config]
[e_rsa_fermat_factorization]
Rounds = 100
```
Note that there is already a lint that is configurable - `e_rsa_fermat_factorization`. This lint checks an RSA keypair for susceptibility to the Fermat factorization attack. The more rounds used, the more likely the lint is to successfully factor a key pair. However, increasing the number of rounds dramatically increases the amount of time taken to lint a single certificate. As such, the default is set to 100 as per CABF requirements and users are free to set this value to something lower (if they wish to lint a large number of certificates and want the batch job to run faster) or to something much higher (if they suspect that a key pair is susceptible, but not trivially so).
## New Lints:
* `e_key_usage_incorrect_length` checks for KeyUsages that are outside the range of possible values.
* `e_incorrect_ku_encoding` check for KeyUsages that are not properly encoded ASN.1 bitstrings.
* `e_rsa_fermat_factorization` checks for key pairs that are susceptible to Fermat factorization.
* `e_superfluous_ku_encoding` checks for KeyUsages that have unnecessary trailing zero-bytes.
* `e_ecdsa_allowed_ku` key usage values keyEncipherment or dataEncipherment MUST NOT be present in certificates with ECDSA public keys
* `e_rsa_allowed_ku_ca` key usage values digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyCertSign, and cRLSign may only be present in a CA certificate with an RSA key
* `e_rsa_allowed_ku_ee` key usage values digitalSignature, nonRepudiation, keyEncipherment, and dataEncipherment may only be present in an end entity certificate with an RSA key
* `e_rsa_allowed_ku_no_encipherment_ca` if Key usage value keyCertSign or cRLSign is present in a CA certificate both keyEncipherment and dataEncipherment SHOULD NOT be present"
* `e_subject_contains_organizational_unit_name_and_no_organization_name` if a subject organization name is absent then an organizational unit name MUST NOT be included in subject
* `e_organizational_unit_name_prohibited` organizationalUnitName is prohibited if...the certificate was issued on or after September 1, 2022
## Bug Fixes:
* Corrected `e_organizational_unit_name_prohibited` to not lint CA certificates.
* Corrected a CABF citation in `e_algorithm_identifier_improper_encoding`
* Corrected an issue `e_ext_tor_service_descriptor_hash_invalid` wherein an OnionV3 certificate may be considered an OnionV2 certificate if a non-onion DNS entry were present in the certificate.
## Changelog
* 137e46e Lint to check for invalid KU lengths (#686)
* 1209017 Prevent OU lint from applying to CA certificates. Add unit test to confirm change of behaviour (#691)
* 44e12c1 Add lint to check for incorrect 'unused' bit encoding in KeyUsages (#684)
* 3f5e40d Lint for RSA close prime Fermat factorization susceptibility (#674)
* e5ee614 Support for Configurable Lints (#648)
* ed9a20f Added lint to check for superfluous zero byte on KU (#682)
* d8b86f7 Lints for allowable key usages as per RFC 8813 Section 3 and RFC 3279 Section 2.3.1 (#678)
* c7955ed Sunset subject:organizationalUnitName (Section 7.1.4.2.2.i, CAB-Forum BR) (#643)
* b7abf25 Add new lint to block organisational unit names as of 1st September 2022 (#675)
* c32f6d3 Fix SPKI Encoding Lint's RSA BR Section (#679)
* ed6287a Zlint incorrectly requires TorServiceDescriptors if V3 onion and DNS name (#677)
**Full Changelog**: https://github.com/zmap/zlint/compare/v3.3.1...v3.4.0-rc1
The ZMap team is happy to share ZLint v3.4.0-rc1 (https://github.com/zmap/zlint/releases/tag/v3.4.0-rc1)
Thank you to everyone who contributes to ZLint!
## Breaking Changes:
No breaking changes were made in this release.
## New Features:
Individual lints may now be (optionally) configurable!
### For Lint Authors
For lint authors, please see [CONTRIBUTING.md](https://github.com/zmap/zlint/blob/master/CONTRIBUTING.md#making-your-lint-configurable) for more details on how to write a lint that may receive optional configurations.
### For users
For users of the CLI tool, configuring a particular lint is as simple as providing a valid `toml` file to ZLint.
`zlint -config configFile.toml mycert.pem`
ZLint also provides a facility for getting a print out of a valid, all default, configuration file such that users do not have to hunt through documentation to discover what lints are configurable and what their fields are.
For example...
`zlint -exampleConfig`
...currently prints to the terminal....
```toml
[AppleRootStorePolicyConfig]
[CABFBaselineRequirementsConfig]
[CABFEVGuidelinesConfig]
[CommunityConfig]
[MozillaRootStorePolicyConfig]
[RFC5280Config]
[RFC5480Config]
[RFC5891Config]
[e_rsa_fermat_factorization]
Rounds = 100
```
Note that there is already a lint that is configurable - `e_rsa_fermat_factorization`. This lint checks an RSA keypair for susceptibility to the Fermat factorization attack. The more rounds used, the more likely the lint is to successfully factor a key pair. However, increasing the number of rounds dramatically increases the amount of time taken to lint a single certificate. As such, the default is set to 100 as per CABF requirements and users are free to set this value to something lower (if they wish to lint a large number of certificates and want the batch job to run faster) or to something much higher (if they suspect that a key pair is susceptible, but not trivially so).
## New Lints:
* `e_key_usage_incorrect_length` checks for KeyUsages that are outside the range of possible values.
* `e_incorrect_ku_encoding` check for KeyUsages that are not properly encoded ASN.1 bitstrings.
* `e_rsa_fermat_factorization` checks for key pairs that are susceptible to Fermat factorization.
* `e_superfluous_ku_encoding` checks for KeyUsages that have unnecessary trailing zero-bytes.
* `e_ecdsa_allowed_ku` key usage values keyEncipherment or dataEncipherment MUST NOT be present in certificates with ECDSA public keys
* `e_rsa_allowed_ku_ca` key usage values digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyCertSign, and cRLSign may only be present in a CA certificate with an RSA key
* `e_rsa_allowed_ku_ee` key usage values digitalSignature, nonRepudiation, keyEncipherment, and dataEncipherment may only be present in an end entity certificate with an RSA key
* `e_rsa_allowed_ku_no_encipherment_ca` if Key usage value keyCertSign or cRLSign is present in a CA certificate both keyEncipherment and dataEncipherment SHOULD NOT be present"
* `e_subject_contains_organizational_unit_name_and_no_organization_name` if a subject organization name is absent then an organizational unit name MUST NOT be included in subject
* `e_organizational_unit_name_prohibited` organizationalUnitName is prohibited if...the certificate was issued on or after September 1, 2022
## Bug Fixes:
* Corrected `e_organizational_unit_name_prohibited` to not lint CA certificates.
* Corrected a CABF citation in `e_algorithm_identifier_improper_encoding`
* Corrected an issue `e_ext_tor_service_descriptor_hash_invalid` wherein an OnionV3 certificate may be considered an OnionV2 certificate if a non-onion DNS entry were present in the certificate.
## Changelog
* 137e46e Lint to check for invalid KU lengths (#686)
* 1209017 Prevent OU lint from applying to CA certificates. Add unit test to confirm change of behaviour (#691)
* 44e12c1 Add lint to check for incorrect 'unused' bit encoding in KeyUsages (#684)
* 3f5e40d Lint for RSA close prime Fermat factorization susceptibility (#674)
* e5ee614 Support for Configurable Lints (#648)
* ed9a20f Added lint to check for superfluous zero byte on KU (#682)
* d8b86f7 Lints for allowable key usages as per RFC 8813 Section 3 and RFC 3279 Section 2.3.1 (#678)
* c7955ed Sunset subject:organizationalUnitName (Section 7.1.4.2.2.i, CAB-Forum BR) (#643)
* b7abf25 Add new lint to block organisational unit names as of 1st September 2022 (#675)
* c32f6d3 Fix SPKI Encoding Lint's RSA BR Section (#679)
* ed6287a Zlint incorrectly requires TorServiceDescriptors if V3 onion and DNS name (#677)
**Full Changelog**: https://github.com/zmap/zlint/compare/v3.3.1...v3.4.0-rc1
Reply all
Reply to author
Forward
0 new messages