On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy < [email protected]> 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 > - 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 > - 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 > - 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 > - signature hash and the hash used for mask generation must be the same > both > in public key parameters in certificate and in signature parameters > - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and > 64 > bytes for SHA-512 > - 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/ Hubert, Thanks for raising this issue in m.d.s.p. I think it's helpful to break the discussion into two (or more) parts. One part worth discussing is the CA policy - that is, what are CAs expected to do or not do, and what constitutes "misissuance". Another part worth discussing is client behaviour - what will NSS (and Mozilla) clients support and not support, despite it not being misissuance, so that there's a clear understanding about what's supported. The reason I make these distinction is that the relevant RFCs - 4055 and 5766 - are bad RFCs. While well-intentioned, they were written at the height of the obsession to 'parameterize all the things' to ensure 'future compatibility' - but the consequence of this is that they introduced a tremendous amount of complexity, while also mistaking risk mitigation for policy advice. Because these RFCs confuse and conflate these two issues, while also introducing significant area for mistakes, we need to be very careful and very precise. On the realm of CA policy, we're discussing two matters: 1) What should the certificates a CA issue be encoded as 2) How should the CA protect and use its private key. While it may not be immediately obvious, both your proposal and 4055 attempt to treat #2 by #1, but they're actually separate issues. This mistake is being made by treating PSS-params on CA certificates as an important signal for reducing cross-protocol attacks, but it doesn't. This is because the same public/private key pair can be associated with multiple certificates, with multiple params encodings (and potentially the same subject), and clients that enforced the silly 4055 restrictions would happily accept these. So I think it's useful to instead work from a clean set of principles, and try to express them: 1) The assumption, although the literature doesn't suggest it's necessary, and it's not presently enforced in the existing WebPKI, is that the hash algorithm for both PKCS#1 v1.5 and RSA-PSS should be limited to a single hash algorithm for the private key. a) One way to achieve this is via policy - to state that all signatures produced by a CA with a given private key must use the same set of parameters b) Another way is to try and achieve this via encoding (as 4055 attempts), but as I noted, this is entirely toothless (and somewhat incorrectly presumes X.500's DIT as the mechanism of enforcing policy a) 2) We want to ensure there is a bounded, unambiguous set of accepted encodings for what a CA directly controls a) The "signature" fields of TBSCertificate (Certs) and TBSCertList (CRL). OCSP does not duplicate the signature algorithm in the ResponseData of a BasicOCSPResponse, so it's not necessary b) The "subjectPublicKeyInfo" of a TBSCertificate 3) We want to make sure to set expectations around what is supported in the signatureAlgorithm fields of a Certificate (certs), CertificateList (CRLs), and BasicOCSPResponse (OCSP). - Notably, these fields are mutable by attackers as they're part of the 'unsigned' portion of the certificate, so we must be careful here about the flexibility 4) We want to define what the behaviour will be for NSS (and Mozilla) clients if/when these constraints are violated - Notably, is the presence of something awry a sign of a bad certification path (which can be recovered by trying other paths) or is it a sign of bad CA action (in which case, it should be signalled as an error and non-functioning) Within the IETF, the TLS WG has, in effect, rejected much of the complexity of 4055 and 5766 by reserving specific algorithm IDs to indicate the constrained set of PSS parameters to a sensible interoperable portion. rsa_pss_sha256 means hashAlg = sha256, mgf = mgf1, mgf-hash-alg = sha256, saltLength = size-of-sha256-digest (32), and doesn't need to reference the trailer bit. If we were to apply those same, common sense principles to public certificates, we would realize that 4055 and 5766 are needlessly complex, and instead use simple OIDs (with no parameters) to indicate an equivalent set of permutations. However, if we chose to avoid simplicitcy and pursue complexity, then I think we'd want to treat this as: 1) A policy restriction that a CA MUST NOT use a private key that has been used for one algorithm to be used with another (no mixing PKCS#1 v1.5 and RSA-PSS) 2) Optionally, a policy restriction that a CA MUST NOT use a private key with one set of RSA-PSS params to issue signatures with another set of RSA-PSS params 3) Optionally, a policy restriction that a CA MUST NOT use a private key with one RSA-PKCS#1v1.5 hash algorithm to issue signatures with another RSA-PKCS#1v1.5 hash algorithm I say "optionally", because a substantial number of the CAs already do and have done #3, and was critically necessary, for example, for the transition from SHA-1 to SHA-256 - which is why I think #2 is silly and unnecessary. In addition 4) A policy restriction that a CA MUST NOT issue a certificate with one set of RSA-PSS params if a certificate has been issued for that public key with another set of RSA-PSS params a) In the case where it's the same CA/organization issuing both certificates, this is to prevent them from creating multiple certs b) In the case of 'hostile' misissuance or incompetent cross-signing, it does raise the question of "Which was issued was first" (e.g. if CA-A issues a cert with RSA-PSS-SHA256, and CA-B issues a cert for that same key with RSA-PSS-SHA384, who misissued?) - but I think we can resolve that by "whichever was disclosed in CCADB later is the misissued one" 5) A policy requirement that CAs MUST encode the signature field of TBSCertificate and TBSCertList in an unambiguous form (the policy would provide the exact bytes of the DER encoded structure). - This is necessary because despite PKCS#1v1.5 also having specified how the parameters were encoded, CAs still screwed this up 6) A policy requirement that CAs MUST encode the subjectPublicKeyInfo field of TBSCertificate in an unambiguous form (the policy would provide the exact bytes of the DER-encoded structure) 7) Changes to NSS to ensure it did NOT attempt to DER-decode the structure (especially given NSS's liberal acceptance of invalid DER-like BER), but instead did a byte-for-byte comparison - much like mozilla::pkix does for PKCS#1v1.5 (thus avoiding past CVEs in NSS) If this is adopted, it still raises the question of whether 'past' RSA-PSS issuances are misissued - whether improperly DER-like BER encoded or mixed hash algorithms or mixed parameter encodings - but this is somewhat an intrinsic result of not carefully specifying the algorithms and not having implementations be appropriately strict. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
