On 01/12/2017 17:06, Ryan Sleevi wrote:
On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Depending on the prevalence of non-public CAs (not listed in public
indexes) based on openssl (this would be a smallish company thing more
than a big enterprise thing), it might be useful to have *two* fixed
salt lengths for each combination of hash algorithm and RSA key length:
1. The salt length=hash length case previously suggested.
2. The salt length=largest permitted by RSA key length and hash length
(OpenSSL default).
Each of these could still be defined in a memcmp-able way.
Yes. You could add flexibility if there was both data to support it and
justification for the added complexity (passed on to all consumers).
I think there is a tremendously high bar to suggest such things are good,
and I don't think it's much useful to discuss what's possible without
having a position in favor (and data to support) or against (and data to
support).
I am saying someone with the resources should check if there is such
data.
If the data shows that OpenSSL-style salt lengths are common in closed
networks, the complexity would consist of:
1. Having two (rather than one) valid value per hash algorithm.
2. The second valid value (OpenSSL default) needs to be computed from
the RSA key length (it's not a fixed value, though test vectors can
be given for common RSA key lengths). In practice there would be
one value (except 2 bytes) for salt lengths < 65536 bits, one for salt
lengths >= 65536 bits (with 3 varying bytes), so a full DER encoder is
not even needed, though most X.509 libraries will already contain a
suitable DER encoder. Salt lengths < 256 bits are already banned by
other parts of policy, salt lengths >= 16Mbit are unrealistic.
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
