Hanno Böck <ha...@hboeck.de> wrote: > Brian Smith <br...@briansmith.org> wrote: > Having new oids with sane pre-defined parameters would vastly simplify > things. Back when I wrote that code I thought changing the standard is > harder than implementing the non-optimal spec, but I might've been > wrong.
To clarify: I'm suggesting that you parse the raw RSA-PSS parameters from the signature and from the public key into a tuple (hashAlgorithm, maskGenAlgorithm, saltLength) like you normally would. Then, for certain tuples, define OIDs that are only used internally in NSS to identify (using the SECOidTag representation) that combination. These OIDs would never be seen on the wire. This would mean, in addition, that instead of having an rsaPSSKey type, that we'd have an rsa_PSS_SHA256_MGF1SHA256_32_key type and an rsa_PSS_SHA384_MGF1SHA384_48_key type. > Such an RFC could also just declare that keys not divisable by 8 are > disallowed and by that fix that problem as well. Sure, but in practice it isn't a problem. Everybody's been doing the same for RSA-PKCS#1.5 forever already. > I don't really know what channels I'd have to go through to pursue > such a preset-OID. Can an OID be defined by an RFC? How does the > interaction between the OID registration and RFCs work? Is this > something the CFRG would do or some other entity in the IETF? As I mentioned above, you don't need to define these OIDs in an RFC, since they would exist only for the purpose of fitting into NSS's API. The purpose of the RFC would be to nail down which (hashAlgorithm, maskGenAlgorithm, saltLength) are allowed and mandatory to support for certificates. Note that Microsoft's documentation hints that they implemented RSASSA-PSS-SHA256 using the tuple (SHA256, MGF1-SHA1, 20) instead of (SHA256, MGF1-SHA256, 32) like I would expect. Perhaps their RSASSA-PSS-SHA384 is (SHA384, MGF1-SHA1, 20) too? If so, is it more important to interop with them than to have all the parameters match in the intuitive way? Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
