You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yubikey Attestation certs can be loaded (along with their key) to a YubiKey.
Loading an alternate certificate to the F9 slot affects the chain construction. It appears that the YubiKey parses the loaded certificate, in order to get the required information.
The YubiKey enforces the following requirements:
It must be X.509 version 2 or 3
The encoded validity dates must be less than 66 bytes
The encoded SubjectName must be less than 1029 bytes
The total length of the certificate must be fewer than 3052 bytes
Looking through my token, the F9 certificate name subject is the same as the issuer on the attestation certs (as expected).
The YubiKey certificates do not appear to have an authority key identifier extension, but they load the same "CN=Yubico PIV Attestation" certificate to many tokens. This simplifies certificate parsing and chain building.
With PIVApplet, each card is generating its own attestation certificate, with the same CN_STRING value. This makes it harder to validate the attestation certs, and requires either a custom applet or issuing certs that exactly match the expected issuer name.
I'd like to submit a patch to bring this up to full compatibility with certificates meeting the YubiKey requirements. It would potentially increase the applet memory used, especially if a large certificate is provided.
Additionally, in accordance with general good practices and to facilitate differentiation between attestation certs, I'd like to add an Authority Key Identifier extension to generated attestation certs if the Subject Key Identifier is present in the F9 attestation cert. This would help tell attestation certificates apart between various issued PivApplet cards.
The text was updated successfully, but these errors were encountered:
Yubikey Attestation certs can be loaded (along with their key) to a YubiKey.
Loading an alternate certificate to the F9 slot affects the chain construction. It appears that the YubiKey parses the loaded certificate, in order to get the required information.
The YubiKey enforces the following requirements:
Looking through my token, the F9 certificate name subject is the same as the issuer on the attestation certs (as expected).
With PIVApplet, the subject name is hard-coded:
The YubiKey certificates do not appear to have an authority key identifier extension, but they load the same "CN=Yubico PIV Attestation" certificate to many tokens. This simplifies certificate parsing and chain building.
With PIVApplet, each card is generating its own attestation certificate, with the same CN_STRING value. This makes it harder to validate the attestation certs, and requires either a custom applet or issuing certs that exactly match the expected issuer name.
I'd like to submit a patch to bring this up to full compatibility with certificates meeting the YubiKey requirements. It would potentially increase the applet memory used, especially if a large certificate is provided.
Additionally, in accordance with general good practices and to facilitate differentiation between attestation certs, I'd like to add an Authority Key Identifier extension to generated attestation certs if the Subject Key Identifier is present in the F9 attestation cert. This would help tell attestation certificates apart between various issued PivApplet cards.
The text was updated successfully, but these errors were encountered: