Support 4096 bit RSA keys for Yubikey 4

[ribbons]

It would be great to be able to generate and import 4096 bit RSA keys with this tool, now that the Yubikey 4 supports 4096 bit RSA keys.

[klali]

YubiKey 4 doesn't support rsa 4096 for piv since it's not defined in the piv specs.

[rcdailey]

Does Yubikey 5 NFC support 4096 RSA keys?

[rthille]

It looks to me like the current(?) spec from 2015 doesn't support anything but 2048-bit RSA keys: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf

[rcdailey]

I am new to Yubikey and was searching Google to see if I can use it to log into my Ubuntu server using my existing 4096 bit RSA keys, but it doesn't seem so :(

[mouse07410]

Yubico offers YubiHSM2 device, which would an overkill for what you seem to need (mostly because it costs 10 times more than a YubiKey), but if money is not a concern - it supports 4096-bit RSA, and many other nice things (e.g., ECDSA, EdDSA, PSS, OAEP).

I've been working with it, and am quite happy - but my office paid for it.

[rthille]

You could always get a Tomu ( https://Tomu.im/ ) and put whatever necessary software on it.

[uschwarz]

Well, looking at a sunset of 12/2022 for 2048-bit RSA keys (BSI TR-02102-1), I guess I don't even need to do feasibility tests with Yubikeys for our org then, and others in the higher ed sector in Germany will be in the same situation.

[arcticskew]

Yubikey 4 and up support 4096 bit keys through PGP just not PIV.

[mouse07410]

And that is a problem, as with the sunset of RSA-2048, usefulness of PIV devices that can't go higher would decline sharply. Since OpenPGP applet cannot be used in PIV context, draw your own conclusions...

[arcticskew]

True though it sounds like the PIV standard itself is the issue not the Yubikey implementation, so there would not be other PIV devices to use instead.

[mouse07410]

I'm sure PIV would not be the first standard that vendors extend when the standard stops being sufficient for the market needs. The one question is when, how, and who would start it.

[mdempsky]

FWIW, NIST SP 800-73-1 reserved algorithm identifier "05" for RSA 3072: https://csrc.nist.gov/publications/detail/sp/800-73/1/archive/2006-03-15

Experimentally (based on a hacky attempt to add it to yubico-piv-tool), it doesn't seem like the Yubikey 5 PIV applet supports this algorithm identifier though.

[deni]

You could always get a Tomu ( https://Tomu.im/ ) and put whatever necessary software on it.

For future reference I wanna add to this that the Tomu is a very different device, mainly in that it does not provide tamper resistance.

[gebi]

There is news on this topic :) (both good and bad). No, 4096 bit is still not a valid RSA size (and it seems never will be), BUT...

The maximum security strength of RSA schemes associated with the bit length of the modulus
is specified in NIST SP 800-57, Part 1 for the 2048, 3072, 7680, and 15360 modulus sizes

Newly specified RSA modulus sizes are

• (3072)
• 7680
• 15360

FIPS 186-5 (Draft) Digital Signature Standard (DSS) - 5.1 RSA Key Pair Generation (page 15) NIST SP800-57 Part 1 Revision 5 - Recommendation for Key Management Part 1 General - Table 2 (page 54) The important bits are in "Table 2: Comparable security strengths of symmetric block cipher and asymmetric-key algorithms"

[bleetsheep]

It shows here that with compression, 4k is supported by the yubikey 5: https://developers.yubico.com/yubico-piv-tool/Actions/key_import.html

yubico-piv-tool -a import-certificate -s 9c -k -i cert_4096.gz -K GZIP

Without compression you can do 3k keys on the yubikey 5 but not sure if compression has any negative effects (if it didn't then we'd always be using compression I suppose, but of course the excellent yubi documentation says no more than "this exists but you go and figure out what implications it has and when to use it").

Doesn't that resolve this ticket, or am I missing some limitation?

[bleetsheep]

Ignore what I said, it doesn't work. The key import documentation says:

The largest accepted keys are of size 2025/3049 bytes for current versions of YubiKey NEO and YubiKey 5, respectively; however, it is possible to import larger certificates but that requires compression in order for it to fit

(emphasis mine)

It never says whether you can do this for keys as well. The yubico-piv-tool man page gives an example where the format is gzipped DER instead of gzipped PEM, contradicting the page I linked above but in both examples importing a certificate rather than a key. The key import documentation does say that the -K argument is valid for both import-key and import-certificate ("Format of the key/certificate being read/written"), so about half the documentation points towards this being possible with either and the other half suggests that maybe this only works with certificates. Also, the key import documentation speaks of bytes, not bits, so without compression (which the newer yubikey-manager doesn't seem to support) a 3049-byte file should fit (a 3855-bit key produces a 3048-byte pem file). Maybe bits and bytes are mixed up here?

Dismissing conjecture based on horrendous documentation, the actual behaviour is this:

• It doesn't work with PEM: $ openssl genrsa 4096 | gzip -9 > key.pem.gz && yubico-piv-tool -a import-key -s 9c -i key.pem.gz -K GZIP Unknown key format. Unable to import private key
• It doesn't work with DER: $ openssl genrsa 4096 | openssl rsa -outform DER | gzip -9 > key.der.gz && yubico-piv-tool -a import-key -s 9c -i key.der.gz -K GZIP Unknown key format. Unable to import private key
• When passing an invalid -K value, it says so, so clearly it's not as if it doesn't know what it's supposed to do with a GZIP value: $ yubico-piv-tool -a import-key -s 9c -i key.pem.gz -K garbage yubico-piv-tool: invalid argument, "garbage", for option '--key-format' ('-K')
• Then again, it's not as if DER format works without compression and a 2k key either: $openssl genrsa 2048 | openssl rsa -outform DER > key.der && yubico-piv-tool -a import-key -s 9c -i key.der -K DER Unknown key format. Unable to import private key
• So what about PEM format? Let's at least do the maximum size they say the Yubikey 5 supports: $ openssl genrsa 3049 > key.pem && yubico-piv-tool -a import-key -s 9c -i key.pem -K PEM Unusable RSA key of 3049 bits, only 1024 and 2048 are supported. Unable to import private key
• Am I really running a yubikey 5?! $ ykman list YubiKey 5 NFC
• Is it yubico-piv-tool that is checking the key size and erroring out, might that be outdated? It's deprecated after all, but ykman doesn't mention anything about compression or gzip so I didn't think that supported this, either. Let's see: $ openssl genrsa 3049 > key.pem && ykman piv import-key 9c key.pem ykman.piv.UnsupportedAlgorithm: Unsupported RSA key size: 3049
• Checking out the source code of ykman, indeed the two supported algorithms are RSA1024 and RSA2048. Do the Debian repositories just have an ancient version without yubikey 5 support? Yep that's true! Let me check if the latest version has better support: https://github.com/Yubico/yubikey-manager/blob/main/yubikit/piv.py#L83 ...... nope only RSA2048.

Yubikey 5 doesn't support anything >2048 bits, no matter what the documentation says about compression and larger keys.

[gebi]

@bleetsheep thx for the great writeup :)!

Yes, and the reason given in another thread why yubico (one dev) does not support keys >2048bit was stated because older versions of the standard i quoted above did not specify longer ones. That's why i wrote about the new draft versions of the standards where longer keysizes are specified now.

btw... on closer inspection of the new specs it looks like they re-worded everything so that even if 4096bit is not explicitely mentioned it is indeed an allowed keysize now, awesome!

NIST.FIPS.186-5-draft.pdf page 15

This standard specifies the use of a modulus whose bit length is an even integer and greater than or equal to 2048 bits. Furthermore, this standard specifies that p and q be of the same bit length—namely, one-half the bit length of n. The maximum security strength of RSA schemes associated with the bit length of the modulus is specified in NIST SP 800-57, Part 1 for the 2048, 3072, 7680, and 15360 modulus sizes [24].

The reference [24] is for (SP) 800-57 Part 1, Rev. 4. where the newest Rev. 5 page 55 reads like

Note that for the FFC and IFC algorithms, the listed key sizes do not necessarily match the key sizes approved in the source documents (e.g., FIPS 186, SP 800-56A, and SP 800-56B). That is, some key sizes may not be listed, or additional key sizes may be provided with their associated security strength. However, estimated security strengths for the FFC, IFC, and ECC algorithms may also be calculated using a formula in IG 7.5.

Thus for all key sizes not explicitely listed they even provide an estimation formular to estimate their security strengths.

For me it seems thus it's perfectly valid no to implement 4096 bit rsa keys in PIV now. @klali that would be just awesome if it's possible :)!

[klali]

For standards you want to look at sp800-78 for identifiers for piv. The interesting topic here isn't really if it's allowed by NIST or not, but there's no PIV identifier for 4096 defined.

[gebi]

damn... you are right of course.

so hoping for a revision 5 of SP 800-78 and see what algorithm identifiers they include there.

for the future me, look out for:

• future draft (does not exist yet): SP 800-78 rev 5 draft <-- wait for this
• next final (does not exist yet): SP 800-78 rev 5 final
• current: SP 800-78 rev 4 final

[bleetsheep]

So it turns out that, while PIV mode doesn't support 4k keys, OpenPGP mode does. So your yubikey can do it, just if you use the PIV interface stuff, it refuses. The thing is that OpenPGP mode is horrible to interface with. Some people managed to work with it by telling GnuPG to use some binary values for things like x509 constraints, for example these scripts allows you to manage a CA with an RSA 4k key from a yubikey: https://github.com/jymigeon/gpgsm-as-ca

It's hacky, doesn't support simply signing a CSR as-is (key is generated by the CA, basically, though you can probably also make it support CSRs, it's just not what the script does at the moment), but it works. Hope this helps, I basically resigned to using a 2k cert with PIV mode, not realizing that PGP mode is not just for PGP keys and then having to start over.

[david-l-riley]

I will verify that the Yubikey 4 absolutely does support 4096-bit RSA; I've used it with mine for years. However, as has been said above, it doesn't exactly support it for PIV because the spec only allows for 2048 bit. It works fine with OpenPGP mode, but as the above comment mentions, that may well not be supported for your use case.

On the other hand, if your use case can support ECDSA, the Yubikey 5 definitely supports that just fine (and I'd test with the 4 but I don't have a machine with a USB-A port handy just at the moment). Here's the output of pkcs11-tool -M for my 5C:

$ pkcs11-tool -M
Using slot 0 with a present token (0x0)
Supported mechanisms:
  SHA-1, digest
  SHA224, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  ECDSA, keySize={256,384}, hw, sign, verify, EC OID, EC uncompressed
  ECDSA-SHA1, keySize={256,384}, sign, verify
  ECDSA-SHA224, keySize={256,384}, sign, verify
  ECDSA-SHA256, keySize={256,384}, sign, verify
  ECDSA-SHA384, keySize={256,384}, sign, verify
  ECDSA-SHA512, keySize={256,384}, sign, verify
  ECDH1-COFACTOR-DERIVE, keySize={256,384}, hw, derive, EC OID, EC uncompressed
  ECDH1-DERIVE, keySize={256,384}, hw, derive, EC OID, EC uncompressed
  RSA-X-509, keySize={1024,3072}, hw, decrypt, sign, verify
  RSA-PKCS, keySize={1024,3072}, hw, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA224-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA256-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA384-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA512-RSA-PKCS, keySize={1024,3072}, sign, verify
  MD5-RSA-PKCS, keySize={1024,3072}, sign, verify
  RIPEMD160-RSA-PKCS, keySize={1024,3072}, sign, verify
  RSA-PKCS-PSS, keySize={1024,3072}, hw, sign, verify
  SHA1-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA224-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA256-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA384-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA512-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify

The problem here is a deficiency in the PIV spec, not the Yubikey (which would not be doing anyone a favor by adding modes out of spec, running the risk of fragmenting the ecosystem down the line if such a thing were ever introduced by later standards).

[kwinz]

I would really love to get away from OpenPGP Smartcards. The issue is not so much the smartcard itself, but that the GnuPG tooling is terrible, especially on Windows. A lot of major issues are unfixed for years as can be seen in their bugtracker. And the whole GPG ecosystem is not known for its technical soundness. https://github.com/rupor-github/win-gpg-agent#deprecation-note---september-2022

The other alternative on Yubikey is the virtual PIV smart card backend. This is an alternative for SSH logins https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PKCS11.html ,git signatures, and small CAs, but in the age of increasing qbits the limit to RSA key length is a bit concerning.

If PIV doesn't update their spec any more, can we please have another key backend in Yubikeys besides PIV and OpenPGP? One that I can access via PKCS11 just like the PIV one?

I don't know if you are purposely sticking to the old not updated PIV standard to sell more YubiHSM, but this issue has existed since 2016, and it's time for a solution that isn't called OpenPGP.

[mouse07410]

PIV applet on the card necessarily complies with the PIV standard, which doesn't define RSA-4096. There's no way to even name such a key under it.

Considering that SSH uses RSA for authentication, there's no urgent drive to move to RSA-4096 now. They're is a need to get PIV standard revised to include Post-Quantum algorithms (Kyber and Dilithium), but that's NIST's job - but Yubico's. I only hope that Yubico will get implementation on the market quickly, once the specs are released.

[sidwarkd]

Can someone confirm that the YubiHSM supports a PKCS#11 interface to import an RSA3072 private key for signing? Been researching this for days and would happily spend the money but need to be guaranteed it will work.

My use case includes a 3rd party tool that uses PKCS#11 to sign firmware binaries with our private key. I have tested this with SoftHSM but would prefer to be able to store our key on a physical device. I cannot regenerate the key, it already exists and has been used to sign production firmware.

[qpernil]

Yes the YubiHSM supports 2048, 3072 and 4096 bit RSA keys, from both libraries and command line.

[ebourg]

As others have also mentioned, the OpenPGP app of the Yubikey 4 and 5 series does support those keys. But you cannot use a PKCS#11 interface to access them.

Actually OpenSC is able to do that, but a certificate must be loaded into the OpenPGP app using the openpgp writecert command.

[sidwarkd]

@ebourg Could you provide some example commands? Specifically, using openpgp to write an RSA-3072 cert to a Yubikey with writecert and then using OpenSC to use that key to sign something. I'm still navigating the learning curve so it would be amazing to see this in action.

[ddscentral]

@ebourg Some examples (preferably with private key generated on Yubikey) ? We plan to deploy Yubikeys for certificate-based authentication and it definitely wouldn't hurt to upgrade the keys to RSA3072 or RSA4096.

[ebourg]

Could you provide some example commands?

I can try to describe the process:

1. If there is an existing X509 certificate and a private key, the private key must be converted to the OpenPGP format. This can be done programmatically, see the PGPKeyConverter class from the Jsign project for an example in Java. Once the private key is in the OpenPGP format, import and copy it to the OpenPGP card:

   gpg --import privatekey.asc
   gpg --edit-key mykey@example.com

2. If the private key was generated by the OpenPGP card, generate a CSR with gpgsm and get the certificate from the CA

3. Import the certificate on the Yubikey, run gpg-card and type:

   writecert OPENPGP.3 < certificate.pem

4. Set the environment variable OPENSC_DRIVER=openpgp and then use the opensc-pkcs11 module. The PKCS#11 interface should now see a key named AUT or SIG depending on the slot used (3 or 1). Theorically the slot 2 could also be used but this isn't supported by OpenSC yet.

[ddscentral]

@ebourg Thanks a lot. I assume all of this should work on Windows as well. Now I'll need to figure out how to make this stuff work with OpenVPN (that's what we're authenticating to).

[sidwarkd]

@ebourg After spending several hours on this I never quite got the correct order of operations on my Yubikey 5 Series which is almost certainly due to my lack of understanding in all this. I can see the signing key in slot 1 using pkcs11-tool but I can't use it to sign with the python library. I get an InvalidData error when the connection tries to close. But again, that is likely my lack of understanding. But I definitely can see things with the PKCS#11 tool on the OpenPGP side so I will correct my previous comment so as not to confuse people.

[ebourg]

@sidwarkd Something that might help is to set the environment variable OPENSC_DEBUG=9, this will print a very verbose output detailing the APDU requests sent by OpenSC and the responses received from the Yubikey. That'll probably reveal the reason behind the error message.

[Headcrabed]

RSA3072 is now listed in NIST SP 800-78-5 (Initial Public Draft) : https://csrc.nist.gov/pubs/sp/800/78/5/ipd @klali So when would yubikey support RSA3072 in PIV mode?

[mohamedhafez]

the release notes seem to say that as of 2.5.0:

ykpiv: cmd: ykcs11: Add support for RSA3072 and RSA4096 key types. Available in firmware 5.7.0 and newer

Does this mean as long as we have a new yubikey with new enough firmware, we can now use RSA4096 in PIV mode? Just checking before I run out and buy a new one

[dainnilsson]

Unfortunately there is no YubiKey available with this capability as of now. If this is included in a future version we will update this thread!

[loicpoulain]

I have the same request, I need pkcs11 crypto RSA 3072 and 4096 operations, any product with >5.7 firmware planned soon?

[dainnilsson]

Unfortunately I cannot share any information on potential upcoming products.

[EatonZ]

My code signing certificate expires soon and was very surprised my current key could not be used for the renewal (RSA 3072 is required). @dainnilsson Please do update this thread as soon as we can order a 5.7 key.🙂 One question - will this update allow code signing certificates on non-FIPS keys or will the FIPS keys still be required?

[danielweck]

My code signing certificate expires soon and was very surprised my current key could not be used for the renewal (RSA 3072 is required).

Same here. We will use eSigner for a while until (hopefully, maybe, never?) there's a solution for our existing Yubikey FIPS 140-2 (we have a 4-series but the 5-series has the same RSA <= 2048 PIV limitation):

• https://support.yubico.com/hc/en-us/articles/360013761699-YubiKey-FIPS-4-Series

• https://support.yubico.com/hc/en-us/articles/360016649199-YubiKey-FIPS-4-Series-Technical-Manual

• https://support.yubico.com/hc/en-us/articles/360021443340-YubiKey-5-NFC-FIPS

• https://docs.yubico.com/hardware/yubikey/yk-tech-manual/fips-specifics.html#piv-fips-140-2-with-yubikey-5-fips-series

As previously mentioned in this thread, YubiHSM supports RSA 3072 code signing but the price is an order of magnitude more: https://www.yubico.com/gb/product/yubihsm-2/

[EatonZ]

@danielweck I am still reviewing options, but I think I will be going with GlobalSign and Google Cloud HSM. There is a post on how to do this here.

It's frustrating I can't use my existing hardware anymore, but hopefully by the time of my next renewal, things here will be sorted out.

[danielweck]

Thanks.

Just out of interest, I ran pkcs11-tool -M from my Mac laptop ( https://github.com/OpenSC/OpenSC/wiki/macOS-Quick-Start ):

/Library/OpenSC/bin/pkcs11-tool -M

===>

Using slot 0 with a present token (0x0)
Supported mechanisms:
  SHA-1, digest
  SHA224, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  ECDSA, keySize={256,384}, hw, sign, verify, EC OID, EC uncompressed
  ECDSA-SHA1, keySize={256,384}, sign, verify
  ECDSA-SHA224, keySize={256,384}, sign, verify
  ECDSA-SHA256, keySize={256,384}, sign, verify
  ECDSA-SHA384, keySize={256,384}, sign, verify
  ECDSA-SHA512, keySize={256,384}, sign, verify
  ECDH1-COFACTOR-DERIVE, keySize={256,384}, hw, derive, EC OID, EC uncompressed
  ECDH1-DERIVE, keySize={256,384}, hw, derive, EC OID, EC uncompressed
  RSA-X-509, keySize={1024,3072}, hw, decrypt, sign, verify
  RSA-PKCS, keySize={1024,3072}, hw, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA224-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA256-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA384-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA512-RSA-PKCS, keySize={1024,3072}, sign, verify
  MD5-RSA-PKCS, keySize={1024,3072}, sign, verify
  RIPEMD160-RSA-PKCS, keySize={1024,3072}, sign, verify
  RSA-PKCS-PSS, keySize={1024,3072}, hw, sign, verify
  SHA1-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA224-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA256-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA384-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  SHA512-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
  RSA-PKCS-OAEP, keySize={1024,3072}, hw, decrypt

...but PIV is the limiting factor here so RSA 3072 is a no-go.

The YubiKey Manager app happily pushed the RSA 3072 code-signing cert onto the hardware device so I thought it'd work ... only to discover failure when invoking signtool.exe at a later stage.

[ebourg]

@kwinz The Yubikey supports RSA 4096, that's not the issue. The issue is a lack of an easy to use pkcs11 interface that can call the OpenPGP applet. Also if you don't mind learning a bit of APDU, the API isn't that difficult to use. If that's not possible then maybe the Yubikey is simply not the right tool for you, fortunately there are other USB HSMs available.

[mouse07410]

LoveTwo comments.

First, the "3rd party spec" that you refer to, is the NIST standard. Both software vendors that use PIV cards in their products (such as Active Directory) and the HW vendors that make PIV cards, comply with it.

Second, it's probably pointless to move to RSA-4096 anyway:

• if Crypto-Relevant Quantum Computer is not built - then RSA-3072 (or even RSA-2048) is plenty good enough; and
• if CRQC is built - then RSA-4096 doesn't help.

It means - the standard needs to move to PQ algorithms, such as NIST ML-KEM. Not waste time adding useless strength to RSA. Common sense suggests that while (hypothetical) AES-1024 or RSA-16384 are cryptographically stronger than what's currently standardized - nobody sane needs them, as "enough is enough".

[kwinz]

Edit: I deleted my above comment since it's unfitting to talk about the lack of a different applet in the issue tracker for software specifically to interact with the PIV applet.

@ebourg

The issue is a lack of an easy to use pkcs11 interface that can call the OpenPGP applet.

My point above is that Yubico decided not to offer an alternative to the OpenPGP or PIV applets to store the RSA keys on the Yubikey 4/5. Not that there was a lack of an easy to use pkcs11 wrapper over the OpenPGP applet.

fortunately there are other USB HSMs available.

I am not sure how that offering from another vendor is inconsistent with my comment.

@mouse07410

First, the "3rd party spec" that you refer to, is the NIST standard. Both software vendors that use PIV cards in their products (such as Active Directory) and the HW vendors that make PIV cards, comply with it. [...] then RSA-3072 (or even RSA-2048) is plenty good enough

Again, I am aware of the NIST standard and the PIV specification. My comment was that there is no reason other than market segmentation not to offer an alternative way to store RSA keys on the Yubikeys, like it is available on the YubiHSM, even when PIV hadn't standardized support for RSA key sizes of 3072bit yet.

[dainnilsson]

There is a new update to share. Yubico has now announced a new YubiKey version which (among other things) adds support for 3072 and 4096 bit RSA keys in the PIV application. More details available here: https://www.yubico.com/blog/empowering-enterprise-security-at-scale-with-new-product-innovations-yubikey-5-7-and-yubico-authenticator-7/

Note: I will most likely not be able to answer questions about the content above, those should probably be directed elsewhere.

[danielweck]

Thanks for the heads-up!

It is unclear if support for RSA 3072+ will be available via PIV (in our case, code signing for Microsoft Authenticode executables). Technically this is already available via OpenPGP even on old series 4 YubiKeys, so I assume the May 2024 5.7 firmware update will broaden availability to PIV.

[dainnilsson]

Thanks for the heads-up!

It is unclear if support for RSA 3072+ will be available via PIV (in our case, code signing for Microsoft Authenticode executables). Technically this is already available via OpenPGP even on old series 4 YubiKeys, so I assume the May 2024 5.7 firmware update will broaden availability to PIV.

That one I can answer! Yes, the availability is specifically for PIV, and can be used for codesigning, although the Yubico Minidriver may be required for that.

[EatonZ]

@dainnilsson Thanks for posting! Just to clarify, we can now have 64 TOTP accounts on the key? The 32 limit was so tiny, so this would be great.

[dainnilsson]

@dainnilsson Thanks for posting! Just to clarify, we can now have 32 TOTP accounts on the key? The 32 limit was so tiny, so this would be great.

You can have 64 TOTP accounts with the new YubiKey.

[ebourg]

I wonder what PIV algorithm identifier they've used for RSA 4096. Is there a specification for that extension?