| commit | 0a2c9938a512bef20e990e6b9180c3eb2a7dffd7 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@chromium.org> | Thu Dec 24 19:38:03 2015 -0500 |
| committer | Adam Langley <alangley@gmail.com> | Thu Jan 28 00:51:14 2016 +0000 |
| tree | cc93b67c2a6b6edf552d06134b04514cc0ad62b1 | |
| parent | f6094e05efd294e15fe7f2e430f391445ee546bb [diff] |
Don't allow the specifiedCurve form of ECParameters in SPKIs. Although RFC 3279 allows both, per RFC 5912, keys must use a named curve rather than spelling out the curve parameters. Although we do not allow arbitrary curves, we do have to (pretty hackishly) recognize built-in curves in ECPrivateKeys. It seems the cause of this was that OpenSSL, unless you set asn1_flag on the EC_GROUP, likes to encode keys by spelling out the parameters. This is in violation of RFC 5915, though probably not in violation of one of the other redundant ECC specifications. For more fun, it appears asn1_flag defaults to *off* in the API and *on* in the command-line tools. I think the original cause was these defaults meant the pre-BoringSSL Android/OpenSSL Chromium port wrote out Channel ID keys in this format. By now this should no longer by an issue, but it'll warrant a bit more investigation to be sure we can drop it. For now, keep this logic out of SPKIs by not calling d2i_ECParameters. d2i_ECParameters is a fairly pointless function when only named curves are allowed. In testing other implementations, none of Firefox, Safari, or IE11/Win will parse such certificates (i.e. the error is fatal and unbypassable). Likewise, because Mac and Windows' underlying libraries reject this, Chrome on Mac and Windows already rejects such things. Thus this change should be compatible. The following is the certificate and key I constructed to test with: -----BEGIN CERTIFICATE----- MIICwjCCAmqgAwIBAgIJANlMBNpJfb/rMAkGByqGSM49BAEwRTELMAkGA1UEBhMC QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp dHMgUHR5IEx0ZDAeFw0xNDA0MjMyMzIxNTdaFw0xNDA1MjMyMzIxNTdaMEUxCzAJ BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l dCBXaWRnaXRzIFB0eSBMdGQwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjO PQEBAiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAA AAEAAAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQaw zFOw9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i8 5uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2 QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE 5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY+cPEox5W4nyD SNsWGhz1HX7xlC1Lz3IiwaNQME4wHQYDVR0OBBYEFKuE0qyrlfCCThZ4B1VXX+Qm jYLRMB8GA1UdIwQYMBaAFKuE0qyrlfCCThZ4B1VXX+QmjYLRMAwGA1UdEwQFMAMB Af8wCQYHKoZIzj0EAQNHADBEAiBATB6aVJxDD6YAxEM4vf6Sbg2Ty334ldXpkNwc TF+SngIgZ/f59kgDLf6YA04iLw1fUv5Wf1nLYJWwgrRFON5+zvw= -----END CERTIFICATE----- -----BEGIN EC PARAMETERS----- MIH3AgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP////////// /////zBbBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6 k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+ kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/////AAAAAP//////////vOb6racXnoTz ucrC/GMlUQIBAQ== -----END EC PARAMETERS----- -----BEGIN EC PRIVATE KEY----- MHcCAQEEIAcPCHJ61KBKnN1ZyU2JaHcItW/JXTB3DujRyc4Ki7RqoAoGCCqGSM49 AwEHoUQDQgAE5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY +cPEox5W4nyDSNsWGhz1HX7xlC1Lz3IiwQ== -----END EC PRIVATE KEY----- BUG=522228 Change-Id: I3723411a633dc07c4640027de07500293f8f7913 Reviewed-on: https://boringssl-review.googlesource.com/6853 Reviewed-by: Adam Langley <alangley@gmail.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: