On Thursday, 23 November 2017 20:22:28 CET Jakob Bohm via dev-security-policy wrote: > 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"
yes > > - 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". yes > 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. I think that referring to the RFCs that define those OIDs would be sufficient > 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. RFC 4055 and RFC 5756 > > - 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. if RSA becomes breakable, the hash used for the signature will have no impact on the ease of breaking RSA - the key size is important > > - 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). that's why I didn't specify any particular sizes - but if you have a CA that has 4096 bit key and signs with SHA256 and a sub CA that has 2048 bit key, it shouldn't sign certificates with SHA384. that being said, a hierarchy that uses different key sizes, but all signatures are signed with SHA256 is also perfectly valid > > - 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. that was the intention - the tuple (signatureHash, mgf1Hash) is what's supposed to have same value for first and second element, and that requirement is supposed to hold for both public key info and signature. Thanks for pointing out that this can be ambiguous. > > - 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-3 will require changes to the policy either way... > > - 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/ -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
