On Monday, 27 November 2017 17:28:02 CET Ryan Sleevi wrote: > On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy < > > dev-security-policy@lists.mozilla.org> 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.
but the latter must be a superset of the former. And it also describes the part that NSS will explicitly support (and thus must test) > 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. the CA can also use sexy primes as the private key, making the private key easy to derive from the modulus... We can't list every possible way you can overturn the intention of the RFCs. we need to assume well-meaning actors, at least to a certain degree > 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) just because the mechanism can be abused, doesn't make it useless for people that want to use it correctly. It still will protect people that use it correctly. > 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 that's already a MUST requirement, isn't it? > b) The "subjectPublicKeyInfo" of a TBSCertificate that's the biggest issue > 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 true, but a). there's no chance that a valid PKCS#1 v1.5 signature will be accepted as an RSA-PSS signature or vice versa, b). I'm proposing addition of only 3 valid encodings, modulo salt size > 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) it's an invalid signature, needs to be treated as that > 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. problem with that solution is that it is not backwards compatible, and given that support for RSA-PSS signatures in the wild dates back to OpenSSL 1.0.1 and Windows 7 (IIRC) - not building on top of it would delay public use of RSA-PSS for at least another half a decade > 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. I don't consider allowing for encoding such restrictions hugely important either, but I don't see a reason to forbid CAs from doing that to CA certificates either, if they decide that they want to do that > 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" +1 > 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 that was because NULL versus empty was ambiguous - that's not the case for RSA-PSS - empty params means SHA-1 and SHA-1 is forbidden, missing params is unbounded so there's nothing to fail interop > 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) that would require hardcoding salt lengths, given their meaning in subjectPublicKeyInfo, I wouldn't be too happy about it looking at OpenSSL behaviour, it would likely render all past signatures invalid and making signatures with already released software unnecessarily complex (OpenSSL defaults to as large salt as possible) > 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. for X.509 only DER is allowed, if the tags or values are not encoded with minimal number of bytes necessary, or with indeterminate length, it's not DER it's BER and that's strictly forbidden -- 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
