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
class TokenSession: TKTokenSession, TKTokenSessionDelegate
These class not respect the key size discovery statement in the norm : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf page 48
C.1 PIV Algorithm Identifier Discovery for Asymmetric Cryptographic Authentication
As illustrated in the authentication mechanisms in Appendix B, an asymmetric cryptographic authentication involves issuing a challenge (request to sign a nonce) to the PIV Card. The relying party issuing the command provides the nonce to be signed, the key reference, and the PIV algorithm identifier as parameters of the command. The nonce is random data generated by the relying party and the key reference is known. The PIV algorithm identifier, on the other hand, is unknown to the relying party and needs to be identified in order to issue the challenge command. The PIV algorithm identifier can be derived from the previous steps of the authentication mechanism. The relying party, prior to issuing the challenge command, retrieved and parsed the X.509 certificate from the card in order to 1) validate the certificate and 2) extract the public key for the pending verification of the signed nonce once returned from the card. It is during the parsing of the X.509 certificate that the PIV algorithm identifier can be identified in two steps:27
Step 1: Algorithm Type Discovery:
The X.509 certificate stores the public key in the subjectPublicKeyInfo field. The subjectPublicKeyInfo data structure has an algorithm field, which includes an OID that identifies the public key’s algorithm (RSA or ECC) as listed in Table 3-4 of SP 800-78.
Step 2: Key Size Discovery:
If the algorithm type, as determined in Step 1, is ECC then the key size is determined by the elliptic curve on which the key has been generated, which is P-256 for all elliptic curve PIV Authentication keys and Card Authentication keys.
If the algorithm type, as determined in Step 1, is RSA then the key size is determined by the public key’s modulus. The public key appears in the subjectPublicKey field of subjectPublicKeyInfo and is encoded as a sequence that includes both the key’s modulus and public exponent.
The norm is not restrictive for the RSA algorithm. The norm instructs to use the modulus from the public key, regardless of the type of key used for generation. Please adjust the function according to these specifications. This allows for key signatures greater than RSA 2048 and is in accordance with the PIV norm. Typically, it is the public certificate, not the private key, that is used. The PIV application does not have knowledge of the private slot or the key size. This data is usually inaccessible to the PIV application. In this context, the correct implementation is to take the modulus of the public key and build the challenge with it. The PIV device knows the truth about the key and it is the device’s responsibility to return an error, not the PIV application’s. If the device returns a bad length, the key is not supported. It is important to respect the role of each. The PIV application does not build the key parameters from the norm; it discovers the algorithm and size from the public key.
The text was updated successfully, but these errors were encountered:
class TokenSession: TKTokenSession, TKTokenSessionDelegate
These class not respect the key size discovery statement in the norm : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf page 48
C.1 PIV Algorithm Identifier Discovery for Asymmetric Cryptographic Authentication
As illustrated in the authentication mechanisms in Appendix B, an asymmetric cryptographic authentication involves issuing a challenge (request to sign a nonce) to the PIV Card. The relying party issuing the command provides the nonce to be signed, the key reference, and the PIV algorithm identifier as parameters of the command. The nonce is random data generated by the relying party and the key reference is known. The PIV algorithm identifier, on the other hand, is unknown to the relying party and needs to be identified in order to issue the challenge command. The PIV algorithm identifier can be derived from the previous steps of the authentication mechanism. The relying party, prior to issuing the challenge command, retrieved and parsed the X.509 certificate from the card in order to 1) validate the certificate and 2) extract the public key for the pending verification of the signed nonce once returned from the card. It is during the parsing of the X.509 certificate that the PIV algorithm identifier can be identified in two steps:27
Step 1: Algorithm Type Discovery:
The X.509 certificate stores the public key in the subjectPublicKeyInfo field. The subjectPublicKeyInfo data structure has an algorithm field, which includes an OID that identifies the public key’s algorithm (RSA or ECC) as listed in Table 3-4 of SP 800-78.
Step 2: Key Size Discovery:
If the algorithm type, as determined in Step 1, is ECC then the key size is determined by the elliptic curve on which the key has been generated, which is P-256 for all elliptic curve PIV Authentication keys and Card Authentication keys.
If the algorithm type, as determined in Step 1, is RSA then the key size is determined by the public key’s modulus. The public key appears in the subjectPublicKey field of subjectPublicKeyInfo and is encoded as a sequence that includes both the key’s modulus and public exponent.
The norm is not restrictive for the RSA algorithm. The norm instructs to use the modulus from the public key, regardless of the type of key used for generation. Please adjust the function according to these specifications. This allows for key signatures greater than RSA 2048 and is in accordance with the PIV norm. Typically, it is the public certificate, not the private key, that is used. The PIV application does not have knowledge of the private slot or the key size. This data is usually inaccessible to the PIV application. In this context, the correct implementation is to take the modulus of the public key and build the challenge with it. The PIV device knows the truth about the key and it is the device’s responsibility to return an error, not the PIV application’s. If the device returns a bad length, the key is not supported. It is important to respect the role of each. The PIV application does not build the key parameters from the norm; it discovers the algorithm and size from the public key.
The text was updated successfully, but these errors were encountered: