1. 25 Jan, 2021 2 commits
    • Kevin Jacobs's avatar
      Bug 1678398 - Add Export/Import functions for HPKE context. r=mt · 10afb436
      Kevin Jacobs authored
      This patch adds and exports two new HPKE functions: `PK11_HPKE_ExportContext` and
      `PK11_HPKE_ImportContext`, which are used to export a serialized HPKE context,
      then later reimport that context and resume Open and Export operations. Only receiver
      contexts are currently supported for export (see the rationale in pk11pub.h).
      
      One other change introduced here is that `PK11_HPKE_GetEncapPubKey` now works as
      expected on the receiver side.
      
      If the `wrapKey` argument is provided to the Export/Import functions, then the
      symmetric keys are wrapped with AES Key Wrap with Padding (SP800-38F, 6.3)
      prior to serialization.
      
      Differential Revision: https://phabricator.services.mozilla.com/D99277
      
      --HG--
      extra : moz-landing-system : lando
      10afb436
    • Kevin Jacobs's avatar
      Bug 1678398 - Update HPKE to draft-07. r=mt · e2528512
      Kevin Jacobs authored
      This patch updates HPKE to draft-07. A few other minor changes are included:
      - Refactor HPKE gtests for increased parameterized testing.
      - Replace memcpy calls with PORT_Memcpy
      - Serialization tweaks to make way for context Export/Import (D99277).
      
      This should not be landed without an ECH update, as fixed ECH test vectors
      will otherwise fail to decrypt.
      
      Differential Revision: https://phabricator.services.mozilla.com/D99276
      
      --HG--
      extra : moz-landing-system : lando
      e2528512
  2. 04 Dec, 2020 1 commit
  3. 10 Nov, 2020 1 commit
  4. 09 Nov, 2020 2 commits
  5. 30 Oct, 2020 1 commit
  6. 23 Oct, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism r=mt,rrelyea · ec5afba5
      Robert Relyea authored
      Summary
      
      This is useful for RSA-OAEP support.
      
      The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
      be present for PKCS#11 calls. This provides required context for OAEP.
      However, PK11_PubWrapSymKey lacks a way of providing this context and
      historically silently converted CKM_RSA_PKCS_OAEP to CKM_RSA_PKCS when
      a RSA key is provided. Introducing a new call will let us indicate
      parameters and potentially support other mechanisms in the future.
      This call mirrors the earlier calls introduced for RSA-PSS:
      PK11_SignWithMechanism and PK11_VerifyWithMechanism.
      
      The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
      be present for PKCS#11 calls. This provides required context for OAEP.
      However, PK11_PubUnwrapSymKey lacks a way of providing this context,
      and additionally lacked a way of indicating which mechanism type to use
      for the unwrap operation (instead detecting it by key type). Introducing
      a new call will let us indicate parameters and potentially support other
      mechanisms in the future.
      Signed-off-by: default avatarAlexander Scheel <ascheel@redhat.com>
      
      Differential Revision: https://phabricator.services.mozilla.com/D93424
      ec5afba5
  7. 14 Oct, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1670835 Crypto Policy Support needs to be updated with disable/enable support · 7dfc0e17
      Robert Relyea authored
      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).
      7dfc0e17
  8. 12 Oct, 2020 1 commit
    • Kevin Jacobs's avatar
      Bug 1631890 - Add support for Hybrid Public Key Encryption (draft-irtf-cfrg-hpke-05). r=mt · bd4ef1c9
      Kevin Jacobs authored
      This patch adds support for Hybrid Public Key Encryption (draft-irtf-cfrg-hpke-05).
      
      Because the draft number (and the eventual RFC number) is an input to the key schedule, future updates will *not* be backwards compatible in terms of key material or encryption/decryption. For this reason, a default compilation will produce stubs that simply return an "Invalid Algorithm" error. To opt into using the HPKE functionality , compile with `NSS_ENABLE_DRAFT_HPKE` defined. Once finalized, this flag will not be required to access the functions.
      
      Lastly, the `DeriveKeyPair` API is not implemented as it adds complextiy around PKCS #11 and is unnecessary for ECH.
      
      Differential Revision: https://phabricator.services.mozilla.com/D73947
      
      --HG--
      extra : moz-landing-system : lando
      bd4ef1c9
  9. 24 Sep, 2020 1 commit
  10. 24 Aug, 2020 1 commit
  11. 14 Jul, 2020 1 commit
  12. 09 Jul, 2020 2 commits
  13. 06 Jul, 2020 1 commit
  14. 05 Jun, 2020 7 commits
  15. 08 May, 2020 1 commit
  16. 05 May, 2020 4 commits
  17. 24 Apr, 2020 1 commit
  18. 16 Apr, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1630721 Softoken Functions for FIPS missing r=mt · 60de8da9
      Robert Relyea authored
      For FIPS we need the following:
      
       1. NIST official Key padding for AES Key Wrap.
       2. Combined Hash/Sign mechanisms for DSA and ECDSA.
      
      In the first case our AES_KEY_WRAP_PAD function addes pkcs8 padding to the
      normal AES_KEY_WRAP, which is a different algorithm then the padded key wrap
      specified by NIST. PKCS #11 recognized this and created a special mechanism to
      handle NIST padding. That is why we don't have industry test vectors for
      CKM_NSS_AES_KEY_WRAP_PAD. This patch implements that NIST version (while
      maintaining our own). Also PKCS #11 v3.0 specified PKCS #11 mechanism for
      AES_KEY_WRAP which are compatible (semantically) with the NSS vendor specific
      versions, but with non-vendor specific numbers. Softoken now accepts both
      numbers.
      
      This patch also updates softoken to handle DSA and ECDSA combined hash
      algorithms other than just SHA1 (which is no longer validated).
      
      Finally this patch uses the NIST KWP test vectors in new gtests for the
      AES_KEY_WRAP_KWP wrapping algorithm.
      
      As part of the AES_KEY_WRAP_KWP code, the Constant time macros have been
      generalized and moved to secport. Old macros scattered throughout the code
      have been deleted and existing contant time code has been updated to use
      the new macros.
      
      Differential Revision: https://phabricator.services.mozilla.com/D71225
      60de8da9
  19. 13 Apr, 2020 1 commit
  20. 26 Mar, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1623374 Need to support the new PKCS #11 Message interface for AES GCM and ChaCha Poly r=mt · d0c96161
      Robert Relyea authored
      Update ssl to use the new PK11_AEADOp() interface.
       1. We restore the use of PK11Context_Create() for AEAD operations.
       2. AES GCM and CHACHA/Poly specific functions are no longer needed as
        PK11_AEADOp() handles all the mechanism specific processing.
       3. TLS semantic differences between the two algorithms is handled by their
        parameters:
             1. Nonce length is the length of the nonce counter. If it's zero, then
             XOR_Counter is used (and the nonce length is the
             sizeof(sslSequenceNumber)).
             2. IV length is the full IV length - nonce length.
             3. TLS 1.3 always uses XOR_Counter.
       4. The IV is returned from the token in the encrypt case. Only in the explict
        nonce case is it examined. (The code depends on the fact that the count in
        the token will match sslSequenceNumber). I did have assert code to verify
        this was happening for testing, but it's removed from this patch it can be
        added back.
       5. All the decrypt instances of XOR_Counter IV creation have been colapsed
        into tls13_WriteNonce().
       6. Even tough PK11_AEADOp returns and accepts the tag separately (for encrypt
        and decrypt respectively). The SSL code still returns the values as
        buffer||tag.
       7. tls13_AEAD() has been enhanced so all uses of AEAD outside of the TLS
        stream can use it instead of their own wrapped version. It can handle streams
        (CreateContext() tls13_AEAD() tls13_AEAD() DestroyContext()) or single shot
        tls13_AEAD(context=NULL). In the later case, the keys for the single shot
        operation should not be resued.
       8. libssl_internals.c in the gtests directory has been updated to handle
        advancing the internal iv counter when we artifically advance the seqNum.
        Since we don't have access to any token iv counter (including softoken),
        The code switches to simulated message mode, and updates the simulated state
        as appropriate. (obviously this is for testing only code as it reaches into
        normally private data structures).
      
      Differential Revision: https://phabricator.services.mozilla.com/D68480
      d0c96161
  21. 06 Apr, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1561637 TLS 1.3 does not work in FIPS mode r=mt · 468dbd90
      Robert Relyea authored
      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
      468dbd90
  22. 30 Mar, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1561637 TLS 1.3 does not work in FIPS mode · f4952cf3
      Robert Relyea authored
      Patch 1 of 2.
      This patch updates softoken and helper functions with the new PKCS #11 v3 HKDF,
      which handles all the correct key management so that we can work in FIPS mode
      
      1) Salts can be passed in as data, as and explicit NULL (which per spec means
      a zero filled buffer of length of the underlying HMAC), or through a key handle
      2) A Data object can be used as a key (explicitly allowed for this mechanism by
      the spec).
      3) A special mechansism produces a data object rather than a key, the latter
      which can be exported. Softoken does not do the optional validation on the pInfo
      to verify that the requested values are supposed to be data rather than keys.
      Some other tokens may.
      
      The old hkdf mechanism has been retained for compatibility (well namely until
      patch 2 is created, tls is still using it). The hkdf function has been broken
      off into it's own function rather than inline in the derive function.
      
      Note: because the base key and/or the export key could really be a data object,
      our explicit handling of sensitive and extractable are adjusted to take into
      account that those flags do not exist in data objects.
      
      Differential Revision: https://phabricator.services.mozilla.com/D68940
      f4952cf3
  23. 19 Mar, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1623374 Need to support the new PKCS #11 Message interface for AES GCM and ChaCha Poly · d733ccc3
      Robert Relyea authored
      PKCS #11 defines a new interface for handling AEAD type ciphers that allow
      multiple AEAD operations without repeating the key schedule. It also allows
      tokens to keep track of the number of operations, and generate IVs (depending
      on the cipher).
      
      This patch:
          1. implement those new functions in softoken.
             With the addition of CKF_MESSAGE_* flags to various mechanism, we need
             to strip them when using the version 2 API of softoken (since there are
             no C_Message* function in version 2). For that we need a separate
             C_GetMechanismInfo function. We use the same trick we used to have
             a separate version function for the V2 interface.
             Also now that the new message functions are in their own file, they
             still need access to the common Session state processing functions.
             those have gone from static to exported within softoken to accomidate
             that. Same with sftk_MapDecryptError() (sftk_MapVerifyError() was also
             made global, though nothing else is yet using it).
             Only C_MessageEncrptInit(), C_EncryptMessage(), C_MessageEncryptFinal,
             C_MessageDecryptInit(), C_DecryptMessage(), and C_MessageDecryptFinal
             are implemented. C_EncryptMessageBegin(), C_EncryptMessageNext(),
             C_DecryptMessageBegin(), and C_DecryptMessageNext() are all
             part of the multi-part withing a multi-part operation and
             are only necessary for things like S/MIME (potentially). If we wanted
             to implement them, we would need more functions exported from freebl
             (and initaead, updateaead, finalaead for each mechanism type).
          2. make those interfaces call aes_gcm and chacha20_poly1503
          (and make adjustments for those ciphers).
            For AES, I added a new function AES_AEAD, which handles both encrypt
            and decrypt. Internally, the gcm functions (both the generic gcm and
            the intel gcm wrapper) had their init functions split into key scheduling
            and counter mode/tag initialization. The latter is still called from
            init, but the former is now for each update call. IV generation is
            handled by a single function in gcm.c, and shared with intel_gcm_wrapper.c
            Since the AES functions already know about the underlying PKCS #11
            mechanism parameters, the new AEAD functions also parse the PKCS #11 GCM
            parameters.
            For Chacha/Poly new aead update functions were created called
            ChaChaPoly1305_Encrypt and ChaChaChaPoly1305_Decrypt. There was no
            Message specific initialization in the existing chacha_init, so no
            changes were needed there. The primary difference between
            _Encrypt/_Decrypt and _Seal/_Open is the fact that the tag is put at
            the end of the encrypted data buffer in the latter, and in a generic
            buffer in the former.
          3. create new pk11wrap interfaces that also squash the api differences
          between the various mechanisms for aead (similiar to the way we do it for
          CBC and ECB crypto today).
            To accomplish this I added PK11_AEADOp() and PK11_AEADRawOp(). Both
            functions handle the case where the token only supports the single shot
            interface, by using the single short interface to simulate the
            Message interface. The PK11_AEADOp() also smooths out the
            differences in the parameters and symantics of the various mechanism
            so the application does not need to worry about the PKCS #11 differences
            in the mechanism. Both use contexts from the standard
            PK11_CreateContext(), so key schedules are done once for each key rather
            than once for each message. MESSAGE/AEAD operations are selected by adding
            the psuedo attribute flag CKA_NSS_MESSAGE to the requested operation
            (CKA_ENCRYPT, CKA_DECRYPT, CKA_SIGN, CKA_VERIFY).
          4. write tests for the new interfaces
            Tests were added to make sure the PK11_AEADRawOp interface works,
            The single shot interface is used to test output of the message interface
            we also use two test only functions to force the connection to use
            the simulation interface, which is also compared to the non-simulate
            inteface. The AES_GCM also tests various IV generators.
      
      Differential Revision: https://phabricator.services.mozilla.com/D67552
      d733ccc3
  24. 18 Mar, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1603628 Update NSS to handle PKCS #11 v3.0 r=ueno r=mt · a95d4e2c
      Robert Relyea authored
      Update to PKCS #11 v3.0 part 2.
      
      Create the functions and switch to the C_Interface() function to fetch the PKCS #11 function table. Also PKCS #11 v3.0 uses a new fork safe interface. NSS can already handle the case if the PKCS #11 module happens to be fork safe (when asked by the application to refresh the tokens in the child process, NSS can detect that such a refresh is not necessary and continue. Softoken could also be put in fork_safe mode with an environment variable. With this patch it's the default, and NSS asks for the fork safe API by default. Technically softoken should implement the old non-fork safe interface when PKCS #11 v2.0 is called, but NSS no longer needs it, and doing so would double the number of PKCS #11 interfaces are needed. You can still compile with fork unsafe semantics, and the PKCS #11 V3.0 module will do the right thing and not include the fork safe flag. Firefox does not fork(), so for firefox this is simply code that is no longer compilied.
      
      We now use C_GetInterface, which allows us to specify what kind of interface we want (PKCS #11 v3.0, PKCS #11 v2.0, fork safe, etc.). Vendor specific functions can now be accessed through the C_GetInterface. If the C_GetInterface function does not exists, we fall bak to the old C_GetFunctionList.
      
      There are 24 new functions in PKCS #11 v3.0:
      C_GetInterfaceList - return a table of all the supported interfaces
      C_GetInterface - return a specific interface. You can specify interface name, version and flags separately. You can leave off any of these and you will get what the token thinks is the best match of the interfaces that meet the criteria. We do this in softoken by the order of the interface list.
      C_SessionCancel - Cancel one or more multipart operation
      C_LoginUser - Supply a user name to C_Login(). This function has no meaning for softoken, so it just returns CKR_OPERATION_NOT_INITIALIZED under the theory that if we in the future want to support usernames, the NSS db would need special initialization to make that happen.
      C_Message* and C_*Message*  (20 functions in all) are the new AEAD interface (they are written generally so that it can be used for things other than AEAD). In this patch they are unimplemented (see the next patch).
      
      This patch adds regular (NSC_) and FIPS (FC_) versions of these functions.
      Also when creating the PKCS #11 v2.0 interface, we had to create a 2.0 specific version of C_GetInfo so that it can return a 2.40 in the CK_VERSION field rather than 3.00. We do this with #defines since all the function tables are generated automagically with pkcs11f.h.
      
      Differential Revision: https://phabricator.services.mozilla.com/D67240
      a95d4e2c
  25. 18 Feb, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1603628 Update NSS to handle PKCS #11 v3.0 r=daiki r=mhoye · ba931199
      Robert Relyea authored
      https://phabricator.services.mozilla.com/D63241
      
      This patch implements the first phase: updating the headers.
      
      lib/util/pkcs11.h
      lib/util/pkcs11f.h
      lib/util/pkcs11t.h
      
      Were updated using the released OASIS PKCS #11 v3.0 header files.
      lib/util/pkcs11n.h was updated to finally deprecate all uses of CK?_NETSCAPE_?.
      
      A new define as added: NSS_PKCS11_2_0_COMPAT. If it's defined, the small
      semantic changes (including the removal of deprecated defines) between the
      NSS PKCS #11 v2 header file and the new PKCS #11 v3 are reverted in favor of
      the PKCS #11 v2 definitions. This include the removal of CK?_NETSCAPE_? in
      favor of CK?_NSS_?.
      
      One notable change was caused by an inconsistancy between the spec and the
      released headers in PKCS #11 v2.40. CK_GCM_PARAMS had an extra field in
      the header that was not in the spec. OASIS considers the header file to be
      normative, so PKCS #11 v3.0 resolved the issue in favor of the header file
      definition. NSS had the spec definition, so now there are 2 defines for this
      structure:
      
      CK_NSS_GCM_PARAMS - the old nss define. Still used internally in freebl.
      CK_GCM_PARAMS_V3 - the new define.
      CK_GCM_PARAMS - no longer referenced in NSS itself. It's defined as
      CK_GCM_PARAMS_V3 if NSS_PKCS11_2_0_COMPAT is *not* defined, and it's defined as
      CKM_NSS_GCM_PARAMS if NSS_PKCS11_2_0_COMPAT is defined.
      
      Softoken has been updated to accept either CK_NSS_GCM_PARAMS or
      CK_GCM_PARAMS_V3. In a future patch NSS will be updated to use
      CK_GCM_PARAMS_V3 and fall back to CK_NSS_GMC_PARAMS.
      
      One other semantic difference between the 3.0 version of pkcs11f.h and the
      version here: In the oasis version of the header, you must define
      CK_PKCS11_2_0_ONLY to get just the PKCS #11 v2 defines. In our version you
      must define CK_PKCS11_3 to get the PCKS #11 v3 defines.
      
      Most of this patch is to handle changing the deprecated defines that have been
      removed in PCKS #11 v3 from NSS.
      
      Differential Revision: https://phabricator.services.mozilla.com/D63241
      ba931199
  26. 11 Feb, 2020 1 commit
  27. 22 Nov, 2019 1 commit
  28. 12 Nov, 2019 1 commit