1. 28 May, 2021 1 commit
    • Daniel Kahn Gillmor's avatar
      certtool: order DN components by scale. · f2b207b3
      Daniel Kahn Gillmor authored
      DN components are expected to be ordered by scale, with the wire format
      representing larger-scale components (like country or organization) before
      smaller-scale components (like state or organizationalUnit).
      
      The bulk of the changes here of course are changes to the target
      certificates in the test suite.
      
      Note that a change was necessary in tests/cert-tests/crq.sh because it
      tests the "interactive" mode of certtool.  If any user is scripting
      certtool in this way, this change will cause a backwards-incompatible
      break.  However, I think this is OK -- the supported scripted/batch
      mode for certtool should use a template file, and I don't think it's
      important to maintain a strict api on the interactive mode.
      
      The main change here is to order the DN from least-specific-to-most,
      in particular:
      
          country, state, locality, org, orgunit, cn, uid
      
      But I've also made an additional arbitrary choice, which is that DC
      (domain component) comes *after* uid.  This was already the case in
      certificate generation, but in *request* generation, it was the other
      way around.  I've changed request generation to match this ordering
      from certificate generation.
      
      Closes: #1243
      
      Signed-off-by: Daniel Kahn Gillmor's avatarDaniel Kahn Gillmor <dkg@fifthhorseman.net>
      f2b207b3
  2. 04 May, 2021 1 commit
    • Daniel Kahn Gillmor's avatar
      certtool: Align warning about --provable with actual code · f5a1b253
      Daniel Kahn Gillmor authored
      
      
      If I try to generate an ed25519 key, it is *not* an ECDSA key.  But I
      see this warning:
      
          0 dkg@host:~$ certtool --generate-privkey --provable --key-type ed25519
          Generating a 256 bit EdDSA (Ed25519) private key ...
          The --provable parameter cannot be used with ECDSA keys.
          1 dkg@host:~$
      
      Looking at the code and documentation, it's clear that --provable only
      works for RSA and DSA.  This fix aligns the warning message with the
      underlying mechanism.
      Signed-off-by: Daniel Kahn Gillmor's avatarDaniel Kahn Gillmor <dkg@fifthhorseman.net>
      f5a1b253
  3. 03 May, 2021 1 commit
  4. 28 Apr, 2021 1 commit
  5. 15 Jun, 2020 1 commit
  6. 29 May, 2020 1 commit
    • Daiki Ueno's avatar
      gnulib: update git submodule · 5b4989dc
      Daiki Ueno authored
      
      
      This brings in the new fopen-gnu module and the RF_SENSITIVE flag for
      fread_file and read_file.  This also adds the following changes to be
      consistent with the latest changes in Gnulib:
      - the callers of fread_file and read_file to be adjusted for the FLAGS
        argument
      - "attribute.h" needs to be used extensively
      Signed-off-by: Daiki Ueno's avatarDaiki Ueno <ueno@gnu.org>
      5b4989dc
  7. 28 May, 2020 1 commit
  8. 14 May, 2020 1 commit
  9. 23 Jan, 2020 1 commit
  10. 23 Dec, 2019 1 commit
  11. 19 Dec, 2019 1 commit
  12. 25 Nov, 2019 1 commit
  13. 20 May, 2019 1 commit
  14. 09 May, 2019 1 commit
  15. 25 Apr, 2019 1 commit
  16. 20 Apr, 2019 1 commit
    • Nikos Mavrogiannopoulos's avatar
      certtool: generate RSA-PSS certificates from RSA keys · d3ee878e
      Nikos Mavrogiannopoulos authored
      
      
      When generating certificates it was not possible to generate
      an RSA-PSS certificate from an RSA key (common scenario). This
      fixes the certificate generation to include such a method.
      
      Ironically there was a test for this scenario but the test
      was limited to checking that the combination of certtool parameters
      succeeded; modified the test to check the textual expression of
      the certificate for the RSA-PSS indicators.
      Signed-off-by: Nikos Mavrogiannopoulos's avatarNikos Mavrogiannopoulos <nmav@redhat.com>
      d3ee878e
  17. 16 Mar, 2019 1 commit
  18. 13 Mar, 2019 2 commits
  19. 26 Nov, 2018 3 commits
  20. 07 Nov, 2018 1 commit
  21. 17 Sep, 2018 1 commit
  22. 13 Aug, 2018 1 commit
  23. 26 Jul, 2018 1 commit
  24. 23 Jun, 2018 2 commits
  25. 19 May, 2018 1 commit
    • Martin Sucha's avatar
      certtool: use larger serial and CRL numbers · ff3c40d9
      Martin Sucha authored
      Serial/CRL numbers can be up to 20 octets in length
      as per RFC 5280, so it should be possible to use
      such numbers as input to certtool. certtool
      only allowed to specify 63-bit numbers in
      template file or interactively (even though
      it generated larger numbers in batch mode
      by default).
      
      This patch allows large numbers to be specified
      as a hexadecimal string. Parsing of decimal numbers
      larger than native integers would require adding
      dependency on libgmp directly to certtool or
      extending the API exposed by GnuTLS library with parsing
      functions. Since most tools (including GnuTLS) display
      serial numbers in hexadecimal, it is not worth the
      trouble to support large decimal numbers.
      
      Default values are unified between batch mode and
      interactive input and their size is extended.
      
      CA/Browser forum recommends CAs to include at least
      64 bits of random data in the certificate serial
      numbers in Baseline Requirements[1] section 7.1, but
      gnutls adds only 32 bits. Some other
      implementations generate default serial numbers
      with more entropy as well, here is the current state
      as of May 2018:
      
      +----------------+-------------------------------+
      | Implementation | Random bits in default serial |
      +----------------+-------------------------------+
      | OpenSSL [2]    | 159                           |
      | CFSSL [3]      | 159                           |
      | wolfSSL [4]    | 128                           |
      | GnuTLS         | 32                            |
      | Mbed TLS [5]   | 0 (defaults to 1)             |
      +----------------+-------------------------------+
      
      The 20 octet field size can fit numbers up to 159 bits
      since the most significant bit must be zero as numbers
      in DER encoding are in two's complement and the serial
      and CRL numbers must be positive.
      
      Default serial numbers are extended to full 159 bits
      allowed by the field size and are completely random,
      which matches other implementations.
      
      CRL numbers have the same size requirements, but also
      need to be monotonic (RFC 5280, section 5.2.3). That's
      why timestamp is used in them. The timestamp portion
      is extended from 31 bits to 39 bits as 31 bits will
      overflow in year 2038. The rest of the available space
      up to 159 bits allowed in the 20 octet limit is filled
      with random bits.
      
      Since the new CRL numbers are larger, the requirement for them
      to be monotonically increasing is preserved when upgrading to a
      newer version. This does not hold the other way around though,
      so after using a newer version of certtool to generate a CRL
      with default number and publishing it, it's not possible
      to use older version anymore to generate subsequent CRLs.
      Unfortunately, there is no easy workaround for users of older
      certtool, since it is not possible to specify CRL numbers
      greater than 63 bits manually prior to this change.
      Users intending to downgrade to older version later are advised
      to specify the CRL numbers in new version of certtool
      manually with values they are smaller than what would get
      generated by default in the old version.
      
      grep does not recognize CRLF line endings generated
      in tests using MinGW, so we need to convert those to
      LF endings for $ in the regex to match test output
      correctly.
      
      datefudge 1.21 that is present in Fedora 26
      image trims the timestamp to 32 bits. That bug was
      fixed in datefudge 1.22 available in the Debian image,
      so we check if datefudge behaves correctly
      and skip the test that uses more than 32 bits if
      datefudge is broken.
      
      [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
      [2] https://github.com/openssl/openssl/blob/6ebb49f3f9c9333611192561979bb799fa1eb76d/apps/apps.c#L1513
      [3] https://github.com/cloudflare/cfssl/blob/5d63dbd981b5c408effbb58c442d54761ff94fbd/signer/local/local.go#L295
      [4] https://github.com/wolfSSL/wolfssl/blob/d60b16c5b8c19cc61db4a5c3f5e085a7a158cd28/wolfcrypt/src/asn.c#L9791
      [5] https://github.com/ARMmbed/mbedtls/blob/84a1107818aaddfd2abe4c5a3478cf84ab2e26b4/programs/x509/cert_write.c#L81
      
      Signed-off-by: Martin Sucha's avatarMartin Sucha <anty.sk+git@gmail.com>
      ff3c40d9
  26. 07 May, 2018 1 commit
  27. 26 Jan, 2018 1 commit
  28. 01 Oct, 2017 2 commits
  29. 24 Sep, 2017 1 commit
  30. 27 Aug, 2017 3 commits
  31. 23 Aug, 2017 1 commit
  32. 15 Aug, 2017 1 commit
  33. 09 Aug, 2017 1 commit