SP 800-78: Cryptographic Algorithms and Key Sizes for Personal Identity Verification |
| Question ID # |
|
Posted by | |
| 1 |
|
Hildegard Ferraiolo |
|
| Question: |
SP 800-73 Part 1 defines four X.509 certificate data objects and there are key references for asymmetric keys given. One assumes that:
Key Reference 9A <==> X.509 Certificate for PIV Authenication
Key Reference 9B <==> X.509 Certificate for Card Authentication
Key Reference 9C <==> X.509 Certificate for Digital Signature
Key Reference 9D <==> X.509 Certificate for Key Management
is this correct?
Furthermore, it is not stated for which of these key pairs the private key is resident on the card and for which key pairs the private key is held outside the card.
|
|
| Answer: |
The correct relationship is as follows:
Key Reference 9A <==> X.509 Certificate for PIV Authentication. The 9A private key is held on the card.
Key Reference 9B: The Card Management Key (aka Card Application Administration Key) is a symmetric key and has no certificate. The 9B symmetric key is held on the card.
Key Reference 9C <==> X.509 Certificate for Digital Signature. The 9B private key is held on the card.
Key Reference 9D <==> X.509 Certificate for Key Management. The 9D private key is held on the card.
Key Reference 9E <==> X.509 Certificate for Card Authentication Key. Note that the Card Authentication Key may be asymmetric or symmetric. It has a
certificate only if it is asymmetric. The private or secret 9E key is held on the card. |
|
| 2 |
|
Hildegard Ferraiolo |
|
| Question: |
| Table 3-3 in SP 800-78-1 uses the Signature Generation Date as input for determining the allowed signature algorithms and key size requirements; however the method that needs to be used to derive this Signature Generation Date, has not been provided. It is therefore unclear as to how an Agency performing a C&A on their Card Issuance System can verify compliance to these cryptographic requirements. |
|
| Answer: |
SP 800 78-1 specifies cryptographic requirements for digitally signed objects based on the date of signature generation. When validating card management systems, determining signature generation date is an essential component of validating the operations. However, signature generation time is not considered by relying parties when validating a credential. As a result, signature generation time was not included as a mandatory field in any of the digitally signed objects on the PIV card.
This specification establishes heuristics for determining signature generation time that may be used when validating card production components. These heuristics are only applicable to new PIV cards. When cards are updated with a new PIV Authentication certificate, out-of-band information (e.g., a table of {credentialIdentifier, issuanceDate} pairs supplied by the issuer) may be required.
FIPS 201 and the supporting document suite specify that the following digitally signed objects appear on each PIV card:
• an X.509 public key certificate (the PIV Authentication certificate);
• a digitally signed CHUID;
• a signed biometric; and
• the ICAO security object.
FIPS 201 also specifies several optional credentials, including three optional asymmetric key pairs. If present, the optional public keys are encoded as digitally signed X.509 public key certificates:
• the Card Authentication certificate;
• the Digital Signature certificate; and
• the Key Management certificate.
X.509 public key certificates do not specify the time of signature generation, but do specify a validity period using the notBefore and notAfter fields. For each of the X.509 certificates, the notBefore time in the certificate should be used as the digital signature generation date.
The digital signatures on the CHUID, biometric, and security object are all encoded as Cryptographic Message Syntax (CMS) external digital signatures, as defined in RFC 3852. RFC 3852 defines the signingTime attribute, which specifies the time at which the signer (purportedly) performed the signing process. If present in a particular object (i.e., the CHUID, biometric, or security object), the signingTime attribute should be used as the signature generation time. For any object that omits the signingTime attribute, the notBefore time encoded in the corresponding PIV Authentication certificate should be used as the signature generation time.
|
|
| 3 |
|
Hildegard Ferraiolo |
|
| Question: |
| Section 3.2.1 – “Specification of Digital Signatures on Authentication Information”, states that “for signatures on the CHUID, 800-73 Security Object, and stored biometrics, the hash algorithm that must be used to generate the signature is determined by the signature generation date”. However, the certificates (1 mandatory and 3 optional) are also signed objects. What is the mechanism to be used to determine the hash algorithm for these since it doesn’t mention certificates in the above-referenced sentence? |
|
| Answer: |
The mechanism to determine the hash-algorithm for digital signature of the X.509 certificates is listed in the table 3.3 of section 3.2.1. Although your quoted sentence does not explicityly mention X.509 certificate, section 3.2.1 (and table 3.3) still applies to the signature requirements of the X.509 certificate: 1) Section 3.2.1 lists the X.509 public key certificates as a digital signed information, along with the CHUID, Biometric information and the Security Object 2) Section 3.2.1 specifies that all digital signed information shall be generated in accordance to Table 3-3.
|
|
| |
