| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=nss-reviewers
There are three changes in the patch which are related to key length processing:
Change RSA_MIN_MODULUS_BITS in blalpit.h from 128 to 1023. This necessitated changes to the following tests: testcrmf.c: up the generated key for the test from 512 to 1024. pk11_rsapkcs1_unittest.cc (in pk11_gtest): skip the min padding test if the MIN_RSA_MODULUS_BITS is more than 736 (The largest hash we support is 512, which fits in an RSA key less then 736. If we can't generate a key less than 736, we can't test minimum padding, but we can never get into that situation anyway now). tls_subcerts_unittest.cc: set our key size to at least RSA_MIN_MODULUS_BITS, and then make sure the policy had a higher minimum key length so we still trigger the 'weakKey' event. pk11kea.c: use 1024 bits for the transfer key now that smaller keysizes aren't supported by softoken.
Expand the add a new flag to meaning of NSS_XXX_MIN_KEY_SIZE beyond it's use in SSL (add the ability to limit signing and verification to this as well). This allows us to set strict FIPS 140-3 policies, where we can only sign with 2048, but can still verify 1024. This part includes: New utility functions in seckey.c: SECKEY_PrivateKeyStrengthInBits(): The private key equivalent to SECKEY_PublicKeyStrengthInBits(). This function could be exported globally, but isn't in this patch. seckey_EnforceKeySize(). Takes a key type and a length and makes sure that length falls into the range set by policy. secsign.c and secvfy.c: add policy length check where we check the other policy flags. nss.h, nssoptions.c: add NSS_KEY_SIZE_POLICY_FLAGS and define flags for SSL, VERIFY, and SIGN. SSL is set by default (to maintain the current behavior). pk11parse.c: add keywords for the new NSS_KEY_SIZE_POLICY_FLAGS. ssl3con.c: use the flags to decide if the policy lengths are active for SSL. policy.txt: Test that the new policy flags are parsed correctly sslpolicy.txt: Add tests to make sure the policy flags are functioning.
Update fips_algorithms.h to make sure the FIPS indicators are exactly compliant with FIPS 140-3 current guidance (RSA 2028 and above, any key size, Legacy verification allowed for 1024, 1280, 1536, and 1792 [1024-1792, step 256]).
The previous attempt to push failed because the pk11_rsapkcs1_unittest.cc
change was eaten in the merge.
Differential Revision: https://phabricator.services.mozilla.com/D146341
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There are three changes in the patch which are related to key length processing:
Change RSA_MIN_MODULUS_BITS in blalpit.h from 128 to 1023. This necessitated changes to the following tests: testcrmf.c: up the generated key for the test from 512 to 1024. pk11_rsapkcs1_unittest.cc (in pk11_gtest): skip the min padding test if the MIN_RSA_MODULUS_BITS is more than 736 (The largest hash we support is 512, which fits in an RSA key less then 736. If we can't generate a key less than 736, we can't test minimum padding, but we can never get into that situation anyway now). tls_subcerts_unittest.cc: set our key size to at least RSA_MIN_MODULUS_BITS, and then make sure the policy had a higher minimum key length so we still trigger the 'weakKey' event. pk11kea.c: use 1024 bits for the transfer key now that smaller keysizes aren't supported by softoken.
Expand the add a new flag to meaning of NSS_XXX_MIN_KEY_SIZE beyond it's use in SSL (add the ability to limit signing and verification to this as well). This allows us to set strict FIPS 140-3 policies, where we can only sign with 2048, but can still verify 1024. This part includes: New utility functions in seckey.c: SECKEY_PrivateKeyStrengthInBits(): The private key equivalent to SECKEY_PublicKeyStrengthInBits(). This function could be exported globally, but isn't in this patch. seckey_EnforceKeySize(). Takes a key type and a length and makes sure that length falls into the range set by policy. secsign.c and secvfy.c: add policy length check where we check the other policy flags. nss.h, nssoptions.c: add NSS_KEY_SIZE_POLICY_FLAGS and define flags for SSL, VERIFY, and SIGN. SSL is set by default (to maintain the current behavior). pk11parse.c: add keywords for the new NSS_KEY_SIZE_POLICY_FLAGS. ssl3con.c: use the flags to decide if the policy lengths are active for SSL. policy.txt: Test that the new policy flags are parsed correctly sslpolicy.txt: Add tests to make sure the policy flags are functioning.
Update fips_algorithms.h to make sure the FIPS indicators are exactly compliant with FIPS 140-3 current guidance (RSA 2028 and above, any key size, Legacy verification allowed for 1024, 1280, 1536, and 1792 [1024-1792, step 256]).
Differential Revision: https://phabricator.services.mozilla.com/D146341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TLS 1.3
We need to be able to select Client certificates based on the schemes sent to us from the server. Rather than changing the callback function, this patch adds those schemes to the ssl socket info as suggested by Dana. In addition, two helpful functions have been added to aid User applications in properly selecting the Certificate:
PRBool SSL_CertIsUsable(PRFileDesc *fd, CERTCertificate *cert) - returns true if the given cert matches the schemes of the server, the schemes configured on the socket, capability of the token the private key resides on, and the current policy. For future SSL protocol, additional restrictions may be parsed.
SSL_FilterCertListBySocket(PRFileDesc *fd, CERTCertList *certlist) - removes the certs from the cert list that doesn't pass the SSL_CertIsUsable() call.
In addition the built in cert selection function (NSS_GetClientAuthData) uses the above functions to filter the list. In order to support the NSS_GetClientAuthData three new functions have been added:
SECStatus CERT_FilterCertListByNickname(CERTCertList *certList, char *nickname, void *pwarg) -- removes the certs that don't match the 'nickname'.
SECStatus CERT_FilterCertListByCertList(CERTCertlist *certList, const CERTCertlist *filterList ) -- removes all the certs on the first cert list that isn't on the second.
PRBool CERT_IsInList(CERTCertificate *, const CERTCertList *certList) -- returns true if cert is on certList.
In addition
* PK11_FindObjectForCert() is exported so the token the cert lives on can be accessed.
* the ssle ssl_PickClientSignatureScheme() function (along with several supporing functions) have been modified so it can be used by SSL_CertIsUsable()
Differential Revision: https://phabricator.services.mozilla.com/D135715
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes from the review:
The while loop was taken out of it's subshell pipe, which prevented the selfserv PID from being passed on to the final selfserv-kill. This eventally lead to a freeze on windows.
The last paragraph of ISO 19790:2012 section 7.2.4.2 states:
All services shall [02.24] provide an indicator when the service utilises an approved cryptographic algorithm, security function or process in an approved manner and those services or processes specified in 7.4.3
This means our libraries need to grow an API or provide some additional information via contexts or similar in order for an application to be able to query this indicator. This can't be just a Security Policy description because ISO 24759:2017 section 6.2.4.2 states:
TE02.24.02: The tester shall execute all services and verify that the indicator provides an unambiguous indication of whether the service utilizes an approved cryptographic algorithm, security function or process in an approved manner or not.
The indicator can't be just a marker over an algorithm either, because it needs to show different values based on whether the algorithm parameters causes the algorithm to run in approved or non-approved mode (ie keys outside of valid range for RSA means RSA is being used in non-approved mode ...)
For NSS, there is a PKCS #11 design:
https://docs.google.com/document/d/1Me9YksPE7K1Suvk9Ls5PqJXPpDmpAboLsrq0z54m_tA/edit?usp=sharing
This patch implments the above design as well as:
1) NSS proper functions to access these indicators from either the pk11wrap layer or the ssl layer.
2) Updates to the ssl tests which will output the value of the
Changes decription by file:
cmd/selfserv/selfserv.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
cmd/strsclnt/strsclnt.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
cmd/tstclnt/tstclnt.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
lib/nss/nss.def
Add the new pk11 functions to access the fips indicator.
lib/pk11wrap/pk11cxt.c
Implement a function to get the FIPS indicator for the current PK11Context.
lib/pk11wrap/pk11load.c
Get the fips indicator function from the PKCS #11 module using the vendor function interface from PKCS #11 v3.0
lib/pk11wrap/pk11obj.c
Implement a function to get the FIPS indicator for a specific PKCS #11 object.
lib/pk11wrap/pk11priv.h
Add a generalized helper function to get the FIPS indicator used by all the other exported functions to get FIPS indicator.
lib/pk11wrap/pk11pub.h
Add function to get the FIPS indicator for the current PK11Context.
lib/pk11wrap/pk11slot.c
Implement a generalized helper function to get the FIPS indicator.
Implement a function to get the FIPS indicator for the latest single shot operation on the slot.
lib/pk11wrap/secmodt.h
Add a new field to hold the fipsIndicator function.
lib/softoken/fips_algorithms.h
New sample header which vendors can replace with their own table. In the default NSS case, the table in this header will be empty.
lib/softoken/fipstokn.c
Add Vendor specific interface for the FIPS indicator to the FIPS token.
lib/softoken/pkcs11.c
Add Vendor specific interface for the FIPS indicator to the non-FIPS token.
Factor out the code tha maps an attribute value to a mechanism flag to it's own file so it can
be used by other parts of softoken. (new function is in pkcs11u.c
Implement the function that returns the FIPS indicator. This function fetches the indicator from either the session or the object or both. The session indicator is in the crypto context (except the last operation indicator, which is in the session itself. The object indicator is in the base object.
lib/softoken/pkcs11c.c
Record the FIPS indicator in the various helper function.
- sftk_TerminateOp is called when a crypto operation had been finalized, so we can store that fips indicator in the lastOpWasFIPS field.
- sftk_InitGeneric is called when a crypto operation has been initialized, so we can make a preliminary determination if the operation is within the FIPS policy (could later change bases on other operations. For this to work, we need the actual mechanism, so pMechanism is now a parameter to sftk_InitGeneric.
- sftk_HKDF - HKDF when used in TLS has the unusual characteristic that the salt could actually be a key. In this case, usually the base key is some known public value which would not be FIPS generated, but the security is based on whether the salt is really a FIPS generated key. In this case we redo the calculation based on the salt key.
lib/softoken/pkcs11i.h
- add the FIPS indicators to the various structures (crypto contexts, sessions, objects).
- add the FIPS indicators function list
- add pMechanism the the sftkInitGeneric function.
- add the helper function to map Attribute Types to Mechanism Flags.
- add the function that will look up the current operation in the FIPS table to determine that it is allowed by policy.
lib/softoken/pkcs11u.c
- include the new fips_algorithms.h (if NSS_FIPS_DISABLED is not on)
- handle the FIPS status for objects and session on creation an copy.
- implement the helper function to map Attribute Types to Mechanism Flags.
- get the key length of a key. This involves getting the key type and then using the key type to determin the appropriate attribute to fetch. Most keys it's simply the CKA_VALUE. ECC is special, we get the key length from the curve. Since only a subset of curves can be FIPS Curves, we use key length to return false for other curves.
- the handle special function handles any unusal semantics for various mechanism types. This function precodes possible mechanism semantics we may need to check. The special handling can be selected by the mechanism table in fips_algorithms.h
- sftk_operationIsFIPS - the actual function to determine if the givelib/n operation is in the FIPS table.
lib/softoken/sftkmessage.c
- just need to update the sftk_InitGeneric function to pass the mechanism.
lib/ssl/ssl3con.c
- and functions to query the underlying crypto contexts to see if the current ssl session is running in FIPS approved mode based on the security policy. It does so by checking the CipherSpecIsFIPS function to verify that both the mac and the encryption algorithm FIPS conforms to the ciphers in the security profile (using PK11_GetFIPSStatus). We check both the cipher specs for read and write. These underlying specs depends on the keys used in these specs being generated with FIPS approved algorithms as well, so this verifies the kea and kdf functions as well.
lib/ssl/sslimpl.h
- ass ssl_isFIPS() so it can be used by other files here in the ssl directory.
lib/ssl/sslinfo.c
- set the new isFIPS field in the existing sslinfo structure. SSL_GetChannelInfo knows how to handle sslinfo structures that are smaller then expected and larger than expected. unknown fields will be set to '0' (so new applications running against old versions will always get zero for new fields). sslinfo that are smaller will only return a the subset the calling application expects (so old applications will not get the new fields).
lib/ssl/sslt.h
- Add the new isFIPS field (must be at the end of the ChannelInfo structure).
lib/util/pkcs11n.h
- add the new FIPS indicator defines.
tests/ssl/ssl.h
- The main changes was to turn on verbose for the coverage tests so we can test the FIPS indicators on various cipher suites. NOTE: this only works with either NSS_TEST_FIPS_ALGORIHTMS set, or a vendor fips_algorthims.h, so vendors will need to do their own test interpretation. While working in ssl.sh I fixed an number of other issues:
- many tests that were skipped in FIPS mode were skipped not because they didn't work in FIPS mode, but because tstclnt requires a password when running in FIPS mode. I've now added the password if the function is running in fips mode and removed the fips restrictions.
- dtls had a race condition. the server side needed to come up before the client, but couldn't end before the client ran. We already had a sleep to guarrentee the former, I added a sleep before sending the server it's data to handle the latter.
- CURVE25519 is the default ECC curve, but it's not a fiPS curve, so I disable it in FIPS mode so we will actually get FIPS indicators when using ECDHE.
- I added TLS 1.3 to the coverage tests.
Differential Revision: https://phabricator.services.mozilla.com/D115034
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
signatures are disabled. r=mt
When libpkix is checking an OCSP cert, it can't use the passed in set of trust anchors as a base because only the single root that signed the leaf can sign the OCSP request. As a result it actually checks the signature of the self-signed root when processing an OCSP request. This fails of the root cert signature is invalid for any reason (including it's a sha1 self-signed root cert and we've disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic code and the current code is the classic code only checks OCSP responses on leaf certs. In the real world, those responses are signed by intermediate certificates (who won't have sha1 signed certificates anymore), so our signature processing works just fine. pkix checks OCSP on the intermediate certificates as well, which are signed by the root cert. In this case the root cert is a chain of 1, and is effectively a leaf. This patch updates the OCSP response code to not check the signatures on the single cert if that cert is a selfsigned root cert. This requires bug 391476 so we still do the other validation checking on the certs (making sure it's trusted as a CA).
Differential Revision: https://phabricator.services.mozilla.com/D94661
|
| | |
| |
| |
| |
| |
| |
| |
| | |
signatures are disabled.
When libpkix is checking an OCSP cert, it can't use the passed in set of trust anchors as a base because only the single root that signed the leaf can sign the OCSP request. As a result it actually checks the signature of the self-signed root when processing an OCSP request. This fails of the root cert signature is invalid for any reason (including it's a sha1 self-signed root cert and we've disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic code and the current code is the classic code only checks OCSP responses on leaf certs. In the real world, those responses are signed by intermediate certificates (who won't have sha1 signed certificates anymore), so our signature processing works just fine. pkix checks OCSP on the intermediate certificates as well, which are signed by the root cert. In this case the root cert is a chain of 1, and is effectively a leaf. This patch updates the OCSP response code to not check the signatures on the single cert if that cert is a selfsigned root cert. This requires bug 391476 so we still do the other validation checking on the certs (making sure it's trusted as a CA).
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support
Policy update
Current state of the nss policy system:
The initial policy patch focused on getting policy working well in handling ssl. The policy infrastructure used two existing NSS infrastructure:
1) Algorithm policies tied the OIDS and
2) the ssl policy constraints first created to handle export policy restrictions.
To make loadable policies work, we added a couple of new things:
1) a policy parser to the secmod infrastructure which allows us to set algorithm policies based on a config file. This file had two sections: disallow= and allow=. Disallow turned off policy bits, and allow turned them on. Disallow was always parsed first, so you could very strictly control your policy map by saying disallow=all allow={exclusive list of allowed algorithms}
2) a new NSS_Option() value that allowed the policy parser to set integer values (like minimum tls version) based on the data in the policy parser.
3) SSL code which is run at ssl_init time that reads the algorithm policies and maps the results to SSL policies.
The resulting loaded policy code, in general, sets the boundaries of what it possible, actually enable/disable of ssl cipher suites are still under program control, and the builtin NSS default values. The only consession to configuration is if a cipher is disallowed by policy, it is also disabled. Allowing a cipher suite by policy that wasn't already enabled, however, doesn't enable that policy by default. Inside the policy restrictions, applications can still make their own decisions on configuration and preference.
At the time the policy system was designed, there were 3 additional features, which were designed, but not specified: disable, enable, and lock.
disable and enable work just like disallow and allow, except the specify what the default settings are. This would allow the policy file to change the underlying default in the case where the application doesn't try to configure ssl on it's own.
lock would make either the policy or configuration 'locked' meaning once the lock has been executed, no further changes to those configurations would be allowed.
What is needed:
We have a need for the following additional features:
1) we want to turn more of the sha-1 hash function off by default. We still need sha-1 digest because it's used in many non-secure cases, but we do want to disable more sha-1 signature usage. Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers can be controlled by policy. We want to disallow a greater range of signature (that is signature use in general).
2) we want to disable more ciphers by default, but need a way to have certain policies (like LEGACY) turn them back on, so that our shipped system is more secure by default.
What this patch provides:
1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The cryptohi code which exports the NSS sign/verify high level code now checks the hash and signing algorithm against this new policy flag and fails if the policy isn't available.
New key words were added to the policy parser for 'all-signature', which implies all signature flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE. NOTE: disable=all/signature and disable=all/all-signature are effective equivalent because cert-signatures eventually call the low level signature functions, but disable=all allow=rsa-pss/all-signature and disable=all allow=rsa-pss/signature are different in that the latter allows all rsa-pss signature and the latter allows rsa-pss signatures, but no on certificates (or on smime in the future)
Also new keywords were added for rsa-pkcs, rsa-pss, and ecdsa for signature algorithms (along with dsa).
2) This patch implements disable and enable. These functions only work on SSL configuration. In the future SMIME/CMS configuration could also be added. Because the policy system is parsed and handled by NSS, and SSL configuration is handled in SSL, we use the same Apply code we used to apply ssl policy to set the inital configuration. The configured enable/disable state is configured in the ALGORTHIM policy system, where one bit says the enable/disable value is active and another bit which gives it's state.
3) two locks have been implented, policy-lock and ssl-lock. These are specified in the parser as flags (flags=policy-lock,ssl-lock). The policy locks all the policy changes: ssl_policy, algorithm policy, and options. It is implemented by two new exported functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first allows applications to test if the policy is locked without having to try changing the policy. The various policy set functions check the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK if it's true.
The ssl-lock changes the state of the policy to locked, and the state cannot be changed back without shutting down NSS. The second is implemented by setting a new Option called NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we can add an SMIME lock in the future. SSL checks the NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite value, and blocks the change if it's set.
4) sslpolicy tests were updated to test the enable, disable, flags=policy-lock, flags=ssl-lock and the new signature primitives.
5) policy tests were updated to be able to run standalone (like all the other all.sh tests), as well as new tests to detect when no signing algorithms have been enabled.
What is not in the patch
1) S/MIME signature policy has been defined for a while, but never hooked up.
2) S/MIME export policy needs to be connected back to the algorithm policy system just like the ssl cipher suites already are.
3) S/MIME default configuration needs to be connected back to the policy system.
4) ECC Curve policy needs to be hooked up with the signature policy (probably should create a generic 'key meets policy' function and have every call it).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialized. r=mt
NSS has several config functions that multiprocess servers must call before NSS is initialized to set up shared memory caches between the processes. These functions call ssl_init(), which initializes the ssl policy. The ssl policy initialization, however needs to happen after NSS itself is initialized. Doing so before hand causes (in the best case) policy to be ignored by these servers, and crashes (in the worst case).
Instead, these cache functions should just initialize those things it needs (that is the NSPR ssl error codes).
This patch does:
1) fixes the cache init code to only initialize error codes.
2) fixes the selfserv MP code to 1) be compatible with ssl.sh's selfserv management (at least on Unix), and 2) mimic the way real servers handle the MP_Cache init code (calling NSS_Init after the cache set up).
3) update ssl.sh server policy test to test policy usage on an MP server. This
is only done for non-windows like OS's because they can't catch the kill signal
to force their children to shutdown.
I've verified that the test fails if 2 and 3 are included but 1 is not
(and succeeds if all three are included).
Differential Revision: https://phabricator.services.mozilla.com/D70948
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part 2 of 2
Use the official PKCS #11 HKDF mechanism to implement tls 1.3.
1) The new mechanism is a single derive mechanism, so we no longer need to
pick it based on the underlying hmac (Note, we still need to know the
underlying hmac, which is passed in as a mechanism parameter).
2) Use the new keygen to generate CKK_HKDF keys rather than doing it by hand
with the random number generator (never was really the best way of doing this).
3) modify tls13hkdf.c to use the new mechanisms:
1) Extract: use the new key handle in the mechanism parameters to pass the
salt when the salt is a key handle.
Extract: use the explicit NULL salt parameter if for the hash len salt of
zeros.
2) Expand: Expand is mostly a helper function which takes a mechanism. For
regular expand, the mechanism is the normal _Derive, for the Raw version
its the _Data function. That creates a data object, which is extractable
in FIPS mode.
4) update slot handling in tls13hkdf.c:
1) we need to make sure that the key and the salt key are in the same
slot. Provide a PK11wrap function to make that guarrentee (and use that
function in PK11_WrapKey, which already has to do the same function).
2) When importing a 'data' key for the zero key case, make sure we import
into the salt key's slot. If there is no salt key, use PK11_GetBestSlot()
rather than PK11_GetInternal slot.
Differential Revision: https://phabricator.services.mozilla.com/D69899
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rrelyea, mt
Reviewed By: mt
Subscribers: HubertKario
Bug #: 1494063
Differential Revision: https://phabricator.services.mozilla.com/D29166
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch increases SSL testing on taskcluster, specifically, running an additional 395 tests on each SSL cycle (more for FIPS targets), and adding a new 'stress' cycle.
Notable changes:
1) This patch removes SSL stress tests from the default `NSS_SSL_RUN` list in all.sh and ssl.sh. If stress tests are needed, this variable must be set to include.
2) The "normal_normal" case is added to `NSS_SSL_TESTS` for all targets. FIPS targets also run "normal_fips", "fips_normal", and "fips_fips".
3) `--enable-libpkix` is now set for all taskcluster "build.sh" builds in order to support a number of OCSP tests that were previously not run.
Differential Revision: https://phabricator.services.mozilla.com/D43283
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: mt
Reviewed By: mt
Bug #: 1553443
Differential Revision: https://phabricator.services.mozilla.com/D32128
|
| |
|
|
|
|
|
|
|
|
|
|
| |
auth, r=mt
Reviewers: mt
Reviewed By: mt
Bug #: 1532312
Differential Revision: https://phabricator.services.mozilla.com/D21936
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: mt
Reviewed By: mt
Bug #: 1528262
Differential Revision: https://phabricator.services.mozilla.com/D21516
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds a new policy keyword "DSA" to explicitly disable DSA in TLS 1.2 or earlier.
We could make this a bit more generic, e.g., by adding "ECDSA", "RSA-PSS" etc. However, considering the current use of policy in [fedora-crypto-policies](https://gitlab.com/redhat-crypto/fedora-crypto-policies), I realized that adding new keywords may cause compatibility problems; because the Fedora configuration has `disallow=ALL`, all new keywords would be disabled by default. I think it's okay for DSA, though.
Reviewers: kaie
Reviewed By: kaie
Bug #: 1493936
Differential Revision: https://phabricator.services.mozilla.com/D6777
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=rrelyea,fkiefer
Summary:
In bug 1413596, we changed SECKEY_GetPrivateKeyType() to return
rsaPssKey, if the private key is restricted to RSA-PSS when importing.
Although the intention of this change was to extend the certutil
output to provide more information about key types, it introduced
inconsistency with the existing code, as SECKEY_GetPublicKeyType()
still returns rsaKey.
This patch partially revert the change and determine the actual
(restricted) key type in a different way, using CERT_GetCertKeyType()
and PK11_GetCertFromPrivateKey().
Reviewers: rrelyea, franziskus
Reviewed By: franziskus
Subscribers: franziskus
Bug #: 1471985
Differential Revision: https://phabricator.services.mozilla.com/D1911
|
| | |
|
| |
|
|
|
|
|
| |
Reviewers: mt
Differential Revision: https://phabricator.services.mozilla.com/D314
|
| |
|
|
| |
r=rrelyea
|
| | |
|
| |
|
|
| |
r=rrelyea
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D50
|
| |
|
|
| |
Differential Revision: https://nss-review.dev.mozaws.net/D264
|
| | |
|
| |
|
|
| |
r=fkiefer
|
| | |
|
| |
|
|
| |
Differential Revision: https://nss-review.dev.mozaws.net/D367
|
| | |
|
| |
|
|
| |
r=kaie (relanding)
|
| | |
|
| | |
|
| |
|
|
| |
r=franziskus
|
| | |
|
| | |
|
| |
|
|
| |
try: -b do -p all -u ssl
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
mode, r=martin.thomson
|
| |
|
|
| |
Elio. Some improvements by Martin that have r=kaie. Some fixes and changes requested by reviewer by Kai. Overall r=martin.thomson
|
| | |
|
| |
|
|
| |
Elio. Some improvements by Martin that have r=kaie. Some fixes and changes requested by reviewer by Kai. Overall r=martin.thomson
|
| | |
|
| | |
|
