On 23/11/2017 13:07, Hubert Kario wrote:
In response to comment made by Gervase Markham[1], pointing out that Mozilla
doesn't have an official RSA-PSS usage policy.
This is the thread to discuss it and make a proposal that could be later
included in Mozilla Root Store Policy[2]
I'm proposing the following additions to the Policy (leaving out exactly which
sections this needs to be added, as that's better left for the end of
discussion):
- RSA keys can be used to make RSASSA-PKCS#1 v1.5 or RSASSA-PSS signatures on
issued certificates
I presume this refers to "CA RSA keys"
- certificates containing RSA parameters can be limited to perform RSASSA-PSS
signatures only by specifying the X.509 Subject Public Key Info algorithm
identifier to RSA-PSS algorithm
I presume that "RSA parameters" is not the same as "RSA public key".
For clarity, please specify what X.509 fields or extensions "RSA
parameters" would be contained in. (Since other past or future
extensions might contain information about other keys that should not be
subject to this policy merely due to its wording).
Also specify any RSA related OIDs numerically to resolve the ambiguity
caused by the historic assignment of competing OIDs for RSA and hash+RSA
combinations.
Also clarify (or refer to a specific existing standard) if and how such
specification would restrict the hash algorithms that can be used with
the subject public key by the certificate holder.
- end-entity certificates must not include RSA-PSS parameters in the Public
Key Info Algorithm Identifier - that is, they must not be limited to creating
signatures with only one specific hash algorithm
This might or might not need to change in the future, e.g. if attacks
against RSASSA-PKCS#1.5 become more significant than e.g. quantum
attacks on RSA public keys.
- issuing certificates may include RSA-PSS parameters in the Public Key Info
Algorithm Identifier, it's recommended that the hash selected matches the
security of the key
The relationship between hash strength and RSA strength is very much a
mixture of current attack speeds, estimates and conflicting opinions.
Especially for CA certificates, it would probably be best practice to
use the largest sizes compatible with the systems that will use and/or
trust the certificates (not to be confused with the systems relying on
any one root store).
- signature hash and the hash used for mask generation must be the same both
in public key parameters in certificate and in signature parameters
Please make sure that cross-signing between hash algorithms that are
trusted at any given time are allowed. For example if an included root
certificate is RSA-PSS with a declared restriction to use only SHA-256,
it should still be able to cross sign an included or non-included
SHA-384 root.
- the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and 64
bytes for SHA-512
Rephrase as "the salt length must equal the output length of the hash
algorithm, e.g. 48 bytes for SHA-384". This would also cover SHA3 and
other "future" algorithms.
- SHA-1 and SHA-224 are not acceptable for use with RSA-PSS algorithm
1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1400844#c15
2 - https://www.mozilla.org/en-US/about/governance/policies/security-group/
certs/policy/
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
