NIST SP 800-89 日本語訳

2. The entity performs an explicit domain parameter validation and obtains an indication of validity (see Section 4.1 for DSA, and ANS X9.62 for ECDSA; for ECDSA, a check that the subgroup order \(n\) and the cofactor \(h\) are selected appropriately for the security strength shall also be included).

DSA domain parameters are explicitly validated using the following procedure or its equivalent if \(p\), \(q\), \(g\), \(\mathit{domain\_parameter\_seed}\), and \(\mathit{counter}\) are known:
Input:

1. \(L\)

The length of \(p\) in bits.

2. \(N\)

The length of \(q\) in bits.

3. \(p\), \(q\), \(g\), \(\mathit{domain\_parameter\_seed}\), \(\mathit{counter}\)

The domain parameters, where \(p\) and \(q\) are primes, \(g\) is the generator, \(\mathit{domain\_parameter\_seed}\) is the domain parameter seed that was used to generate \(p\) and \(q\), and \(\mathit{counter}\) was obtained during the generation of \(p\) and \(q\).

1. \(\mathit{status}\) The status returned from the validation routine, where \(\mathit{status}\) is either \(\boldsymbol{g}\mathbf{\_partially\_validated}\), \(\boldsymbol{g}\mathbf{\_fully\_validated}\) or INVALID.

Comment: Verify the values of the \((L, N)\) pair specified in FIPS 186-3.

1. Verify that the \((L, N)\) pair is valid. If \((L, N)\) is not in the list of Approved pairs (see FIPS 186-3), then return INVALID.

2. Verify that \(p\) and \(q\) were generated using one of the prime generation algorithms specified in Appendix A.1 of FIPS 186-3², and execute the appropriate validation algorithm. If \(p\) and \(q\) were not generated as specified in FIPS 186-3, or the validation algorithm returns INVALID, then return INVALID. Otherwise, go to step 3.

3. If \(g\) was generated using the unverifiable generation method specified in Appendix A.2.1 of FIPS 186-3, then go to step 4. Otherwise, go to step 5.

4. Perform a partial validation of \(g\) using the process specified in Annex A.2.2 of FIPS 186-3. If PARTIALLY VALID is returned, then return \(\boldsymbol{g}\mathbf{\_partially\_validated}\). Otherwise, return INVALID.

5. If \(g\) was generated using the verifiable generation method specified in Appendix A.2.3 of FIPS 186-3, perform the validation process specified in Appendix A.2.4 of FIPS 186-3. If this process returns INVALID, then return INVALID. Otherwise, return \(\boldsymbol{g}\mathbf{\_fully\_validated}\).

1. \(p\), \(q\) The primes.

2. \(g\) The generator.

3. \(y\) The public key to be validated with respect to \(p\), \(q\) and \(g\).

1. \(\mathit{status}\) The status returned from the validation routine, where \(\mathit{status}\) is either VALID or INVALID.

1. Verify that \(2 \le y \le p-2\). Comment: Ensure that the key has the unique correct representation and range in the field.

2. Verify that \(y^q \equiv 1 \bmod p\). Comment: Ensure that the key has the correct order in the subgroup.

It is possible for an adversary to maliciously construct an invalid candidate RSA public key that passes all the above specified plausibility tests. However, a system error that results in an invalid candidate RSA public key is likely to be detected. The plausibility tests detect some invalid candidate RSA public keys that are easily broken (e.g., where the public exponent is one, or where the modulus is very easily factored). The following is an example of a method that includes all the specified tests: a) Length of the modulus: Check that the length of the modulus \(n\) (\(\mathit{nlen}\)) is a length specified in FIPS 186-3. If the desired security strength is known, then the length shall be appropriate for that security strength.

b) Size of the public exponent \(e\): Check that the value of the public key \(e\) lies in the range specified in FIPS 186-3. If the desired security strength is known, then the range shall be appropriate for that security strength. c) Oddness: Check that \(n\) and \(e\) are odd. d) Compositeness: Check that \(n\) fails an Approved primality test. Approved primality tests are provided in FIPS 186-3. If \(n\) is valid, the test will indicate that \(n\) is a composite number, as the Approved probable prime tests prove compositeness when they fail to indicate that the number is a probable prime.

e) Not a power of a prime: Check that \(n\) is not a power of a prime, i.e., there are no integers \(b \ge 2\), \(c \ge 2\) such that \(n = b^c\). This can be done by obtaining an output of COMPOSITE AND NOT A POWER OF A PRIME using the enhanced Miller-Rabin primality test in FIPS 186-3. f) No very small factors: Check that \(\mathbf{GCD}(n, r) = 1\) where \(r\) is (in decimal). 1451887755777639901511587432083070202422614380984889313550570919659315177065956574359078912654149167643992684236991305777574330831666511589145701059710742276692757882915756220901998212975756543223550490431013061082131040808010565293748926901442915057819663730454818359472391642885328171302299245556663073719855.

Note that the value of \(r\) is the product of the 132 smallest odd primes, from 3 to 751. This value is used to determine that the factors of \(n\) (i.e., \(p\) and \(q\)) are not less than 751. More potential small factors greater than 751 may also be tested in a similar fashion, if desired.

Providing/obtaining assurance of possession normally requires explicit actions. However, once the necessary actions have been taken, the assurance obtained may be leveraged as assurance of private key possession by the owner during some reasonable period containing the time at which those actions were performed. It may be appropriate to periodically repeat the process of explicitly providing/obtaining assurance of possession, due to the possible lessening of assurance over time (see Section 6.1). In the case of DSA, the private key is denoted as \(x\), coupled with the (public) domain parameters; for ECDSA, the private key is \(d\), coupled with the (public) domain parameters. No explicit assurance of possession is required for the DSA and ECDSA per-message secret number \(k\) (which may be considered as a key). For RSA, the private key is denoted as the private value \(d\), coupled with the (public) modulus, or an equivalent representation. For DSA and ECDSA, assurance of domain parameter validity shall be obtained prior to obtaining assurance of private key possession. For all digital signature algorithms, assurance of the validity of the public key shall be obtained prior to or concurrently with obtaining assurance of the possession of the associated private key.

Assurance of private key possession is explicitly provided at a specific point in time, herein referred to as the \(\mathit{assurance\_time}\). The passage of time may adversely affect the level of confidence that a relying party has in the owner’s continued possession of that key. For example, the possible occurrence of one or more of the following events would negatively impact assurance of possession:

On the other hand, it may be reasonable to infer that the owner was in possession of the correct private key for some period of time prior to the \(\mathit{assurance\_time}\); a relying party’s organization must decide whether or not such an inference is acceptable. For the purposes of this discussion, three levels of assurance are defined relative to the \(\mathit{assurance\_time}\): HIGH, MEDIUM and LOW. An organization may choose to implement additional or fewer assurance levels. Figure 1 depicts a simple model for changes in the level of assurance of possession over an extended period of time. In this figure, \(t_A\) denotes the actual time when assurance of private key possession is explicitly provided to the relying party. (In practice, one may have to accommodate the use of an approximation.) The quantities \(a\), \(b\) and \(c\) are values selected by the relying party and/or the relying party’s organization:

• \(a\) and \(b\) are lengths of time before and after the point at which assurance of private key possession was explicitly provided to the relying party. In this model, the relying party has a HIGH level of assurance that the owner of the key pair is in possession of the private key between times \(t_A - a\) and \(t_A + b\).

• \(c\) is a length of time after \(t_A + b\). Assurance that the owner possesses the private key degrades between times \(t_A + b\) and \(t_A + b + c\) to a LOW level of assurance.

• The relying party has a LOW level of assurance that the owner possesses the private key after time \(t_A + b + c\).

6.2 Assurance of Possession Model with an Estimated \(\mathit{assurance\_time}\)

• \(a\), \(b\) and \(c\) are as defined for Figure 1.

• \(t_G\) represents the precise time that the assurance_time is explicitly provided.

• \(t_1\) is a time that is trusted by the relying parties to precede (or equal) \(t_G\).

• \(t_2\) is a time that is trusted by the relying parties to follow (or equal) \(t_G\).

• \(d\) is the maximum time lapse allowed between \(t_1\) and \(t_2\).

• \(t_A\) is the assigned \(\mathit{assurance\_time}\). It must satisfy \(t_1 \le t_A \le t_2\). In this Recommendation, for the purpose of simplicity, \(t_{\mathrm{A}}\) will be set equal to either \(t_1\) or \(t_2\) (see Sections 6.3.1.2 and 6.3.2.1).

Figure 2: Assurance Model based on an Estimated \(\mathit{assurance\_time}\)

Values for \(a\), \(b\), \(c\) and \(d\) are selected by relying parties or their organizations with regard to the following:

1. \(a\), \(b\) and \(c\) should be selected with regard to the judgments to be made about the validity of the digital signatures processed. Consideration should also be given to the ease (or difficulty) of (repeatedly) using a given method to explicitly obtain assurance of possession.

2. A value of \(d\) shall be selected such that \(d\) is less than one half the minimum of \(a\) and \(b\) (i.e., \(d < \frac{1}{2} \mathbf{min}(a, b)\)). An interval of length \(d\) must allow sufficient time for the acquisition of time \(t_1\), the actions required to provide/obtain assurance, and the acquisition of time \(t_2\). In particular, expected transmission times between various parties who must exchange information should be considered when selecting \(d\).

Depending on the trustworthiness of the estimated \(t_A\), a relying party may initially have a HIGH, MEDIUM, or LOW level of assurance that the owner of the key pair is in possession of the private key between times \(t_A - (a-d)\) and \(t_A + (b-d)\) (see Sections 6.3.1.3 and 6.3.2.2) If the assurance level is initially determined to be either HIGH or MEDIUM, assurance that the owner possesses the private key degrades between times \(t_A + (b-d)\) and \(t_A + (b-d) + c\) to a LOW level. The relying party has only a LOW level of assurance that the owner possesses the private key after time \(t_A + (b-d) + c\).

When assurance of private key possession is explicitly provided using one of the methods described above, the \(\mathit{assurance\_time}\) shall be recorded.

A nonce³ supplied by the intended verifier. If this option is used, the nonce shall contain a random component with entropy⁴ equal to or greater than the security strength associated with the private key for which assurance of possession is sought. If the assurance message will not include a TST, and the relying parties require that an \(\mathit{assurance\_time}\) be recorded upon successful verification of the assurance signature, then the nonce should also contain a verifier-supplied timestamp component that unambiguously represents the time that the nonce was made available for inclusion in the assurance message.

4. The public key corresponding to the private key for which assurance of possession is sought. The public key may be omitted if the (claimed) signatory’s “commitment” to the key pair has been unambiguously demonstrated before the exact form of the assurance message could have been known by the signatory. Such commitment must precede the time provided in the trusted timestamp token (i.e., the \(\mathit{timestamp\_time}\)) mentioned above, or – in the absence of a TST – must precede the time provided in a timestamp component included in a verifier-supplied nonce. If neither the public key of the claimed signatory nor a time trusted by the relying parties will be included in the assurance message, then the relying parties must obtain trustworthy evidence that the (claimed) signatory committed to the key pair in question before the verifier-supplied nonce was made available for use in the computation of the assurance signature. Commitment to a key pair can be demonstrated, for example, by the presence of a trusted timestamp on a certificate (signed by a CA whose signature is trusted by the verifier and other relying parties) that contains the public key of the key pair and identifies the claimed signatory as the owner. Relying parties must be aware of the security strength provided by the CA’s signature. The security strength provided by the CA’s digital signature shall meet or exceed the security requirements of the requesting entity and relying party (see SP 800-57); Commitment could also be demonstrated by the existence of a signature that was previously generated by the same claimed signatory that can be successfully verified using the same public key; such a signature shall be known to have been generated at a time when the claimed signatory was the owner, and at a time before the exact form of the current assurance message (in particular, the values of included timestamps and/or nonces) could have been known by the signatory.

6.3.1.2 Assigning the \(\mathit{assurance\_time}\) for an Assurance Signature

Following the successful verification of an assurance signature, the assignment of a value to \(\mathit{assurance\_time}\) is affected by the form of the assurance message and the trustworthiness of the sources for the times \(t_1\) and \(t_2\) that bracket the actual time (\(t_G\)) at which the assurance signature was generated (see Section 6.2 and Figure 2.)

As defined in Section 6.2, \(t_1\) is a time that either precedes or is equal to the time that the assurance signature was generated. There may be several possibilities for \(t_1\), including one or more of the following:

• If the assurance message includes a timestamp from a TTA (trusted by the relying parties), the \(\mathit{timestamp\_time}\) in that timestamp is a candidate for \(t_1\).

• If the assurance message includes a verifier-supplied time (for example, as a timestamp component of a verifier-supplied nonce), that time is a candidate for \(t_1\).

• If the assurance message includes a verifier-supplied nonce, and the verifier has recorded the time that the nonce was first made available to the claimed signatory, the recorded time is a candidate for \(t_1\).

The candidate time whose source is considered most trustworthy by the relying parties should be used as \(t_1\). To choose between equally trustworthy candidates, preference should be given to the latest time that is included in the assurance message.

As defined in Section 6.2, \(t_2\) is a time that either follows or is equal to the time that the assurance signature was generated. There may be multiple possibilities for \(t_2\), including

• If the assurance signature is included as part of the \(\mathit{timestamped\_data}\) in a TST obtained from a TTA (trusted by the relying parties), the \(\mathit{timestamp\_time}\) in that timestamp is a candidate for \(t_2\).

• If the verifier has recorded the time that the assurance signature was received, the recorded time of receipt is a candidate for \(t_2\).

• If the verifier has recorded the time that the assurance signature was verified, the recorded verification time is a candidate for \(t_2\).

The candidate whose source is considered most trustworthy by the relying parties should be used as \(t_2\). To choose between equally trustworthy candidates, preference should be given to the earliest time.

Assuming that the assurance signature has been successfully verified, and that an acceptable degree of accuracy (\(d\)) has been selected by the relying parties, the estimated \(\mathit{assurance\_time}\) (\(t_A\)) shall be determined as follows:

then time \(t_1\) shall be used as the \(\mathit{assurance\_time}\).

b. If \(t_2 - t_1 \le d\) units, and the source of \(t_1\) is less trustworthy than \(t_2\), then time \(t_2\) shall be used as the \(\mathit{assurance\_time}\).

c. If \(t_2 - t_1 > d\) units, then assurance of possession has not been provided, and there is no value assigned to \(\mathit{assurance\_time}\).

If the assurance signature cannot be verified, then assurance of private key possession has not been provided, and there is no value assigned to \(\mathit{assurance\_time}\).

Following the successful verification of an assurance signature and the assignment of the \(\mathit{assurance\_time}\) (see Section 6.3.1.2), the initial level of assurance (LOW, MEDIUM or HIGH) should be assigned as follows:

a. If the time used to determine the \(\mathit{assurance\_time}\) was obtained from a timestamp token provided by a TTA trusted by the relying parties, then the initial assurance level is HIGH.

b. If the time used to determine the \(\mathit{assurance\_time}\) was not obtained from a TTA, but was obtained by the verifier from a source whose accuracy is trusted by the relying parties, then the initial assurance level is MEDIUM.

c. If the time used to determine the \(\mathit{assurance\_time}\) was obtained by the verifier from a source of unknown accuracy, then the initial assurance level is LOW.

6.3.2.1 Assigning the \(\mathit{assurance\_time}\) for the Regeneration of Keys

1. \(t_1\) is a time that either precedes or is equal to the time at which the owner’s currently held keys – along with any other required data – were made available to the (trusted) party performing the regeneration⁵;

2. \(t_G\) is the time that the regenerated key(s) were actually compared to those currently held by the owner; and

3. \(t_2\) is a time that either follows or is equal to the time at which the regenerated key(s) were actually compared to those currently held by the owner.

The entity that regenerates the key(s) is encouraged to do so as soon after \(t_1\) as possible, and \(t_2\) should be acquired as soon after regeneration and comparison as possible.

Assuming that the regenerated key(s) have been successfully compared to the keys currently held by the owner, and that an acceptable degree of accuracy (\(d\)) has been selected by the relying parties, the estimated \(\mathit{assurance\_time}\) (\(t_A\)) shall be determined as follows:

a. If \(t_2 - t_1 \le d\) units, and the source of \(t_1\) is at least as trustworthy as the source of \(t_2\), then time \(t_1\) shall be used as the \(\mathit{assurance\_time}\).

b. If \(t_2 - t_1 \le d\) units, and the source of \(t_1\) is less trustworthy than \(t_2\), then time \(t_2\) shall

be used as the \(\mathit{assurance\_time}\). c. If \(t_2 - t_1 > d\) units, then assurance of possession has not been provided, and there is no value assigned to \(\mathit{assurance\_time}\). If the regenerated key(s) do not match those currently held by the owner, then assurance of private key possession has not been provided, and there is no value assigned to \(\mathit{assurance\_time}\).

If the regenerated key(s) have been successfully compared to the keys currently held by the owner, and the \(\mathit{assurance\_time}\) (\(t_A\)) is assigned as in Section 6.3.2.1, then the initial

assurance level should be assigned as follows:

a. If the time used to determine the \(\mathit{assurance\_time}\) was obtained from a timestamp token provided by a TTA that is trusted by the relying parties, then the initial assurance level is HIGH.

b. If the time used to determine the \(\mathit{assurance\_time}\) was not obtained from a TTA, but was obtained from a source whose accuracy is trusted by the relying parties, then the initial assurance level is MEDIUM.

c. If the time used to determine the \(\mathit{assurance\_time}\) was obtained from a source of unknown accuracy, then the initial assurance level is LOW.

⁵ For example, \(t_1\) is the time that the owner provides the keys to its own regeneration process, or the time that a TTP that will be performing the regeneration is provided with the keys by the owner.

During normal operations, parties may need to determine a level of assurance of private key possession by the (claimed) signatory at the (apparent) time of generation of the signature of a generic message, i.e., a message that does not fulfill the requirements of an assurance message (see Section 6.3.1.1). In the following, the signature of a particular generic message will be referred to as the signature-in-question. The signature-in-question may have been generated either before, concurrently with, or after some \(\mathit{assurance\_time}\) (\(t_A\)) that was established when assurance

of possession by the (claimed) signatory was explicitly provided for the private key corresponding to the public key used for verification of the signature-in-question. The \(\mathit{assurance\_time}\) and the initial assurance level associated with that provision of assurance may be used to assess a level of assurance that the (claimed) signatory also possessed the private key at the time that the signature-in-question was generated. It is assumed that \(t_A\) and the initial level of assurance have been established as specified

in either Section 6.3.1 or Section 6.3.2. Let the time that the signature-in-question was generated be denoted as \(t_s\). This \(t_s\) may have a known value⁶, may only be known to

belong to a certain interval of time⁷, or it may be completely unknown. When \(t_s\) is known with sufficient accuracy, the level of assurance of private key

possession by the (claimed) signatory at the time of generation of the signature-in-question may be assigned as follows (in accordance with the assurance of possession model described in Section 6.2, using values for \(a\), \(b\), \(c\) and \(d\) that are known and have been agreed upon by the relying parties):

• If \((t_A - (a - d)) \le t_s \le (t_A + (b - d))\), then the level of assurance associated with the signature-in-question is equal to the initial assurance level.

• The level of assurance gradually degrades from the initial level to LOW for \((t_A + (b - d)) \le t_s \le (t_A + (b - d) + c)\), and

• If \(t_s > (t_A + (b - d) + c)\), then the level of assurance associated with the signature-in-question is LOW.

In cases where the generation time for the signature-in-question is not known relative to the \(\mathit{assurance\_time}\), the level of assurance is LOW (at best).

⁶ For example, the time \(t_s\) could be provided within the generic message as a transmission time, as is commonly done in email messages.

⁷ For example, suppose that the generic message \(M_R\) corresponding to the signature-in-question is a response to a previous message \(M_P\), and that message \(M_R\) contains information provided in message \(M_P\) that could not have been determined prior to receiving \(M_P\). It follows that \(t_s\) occurred between the time \(M_P\) was sent and the time \(M_R\) was received (along with the signature-in-question).

The owner shall:
a. Determine the appropriate value of \(d\). For example, \(d\) may be selected in accordance with the assurance of possession model described in Section 6.2, along with appropriate values of \(a\), \(b\) and \(c\).
b. Determine a trusted value for \(t_1\) (see Sections 6.2 and 6.3.1.2).
c. Generate a new private-key-possession assurance message (see Section 6.3.1.1).
d. Sign the assurance message using the private key for which assurance is to be obtained, thus generating an assurance signature.
e. Verify the assurance signature using the public key that corresponds to the private key.
f. If verification is successful:

• Determine a trusted value for \(t_2\) (see Sections 6.2 and 6.3.1.2).

• Provided that \(t_1 \le t_2 \le t_1+d\), assign and record the \(\mathit{assurance\_time}\) and the initial assurance level (see Sections 6.3.1.2 and 6.3.1.3).

a. The owner shall determine the appropriate value of \(d\). For example, \(d\) may be selected in accordance with the assurance of possession model described in Section 6.2, along with appropriate values of \(a\), \(b\) and \(c\).
If the TTP will be responsible for assigning the \(\mathit{assurance\_time}\), then the value of \(d\) shall be made known to the TTP.
b. The owner and/or the TTP shall determine a value for \(t_1\) that is trusted by the owner (see Sections 6.2 and 6.3.1.2).
c. The owner shall generate a new private-key-possession assurance message (see Section 6.3.1.1).

• The owner and/or the TTP shall determine a value for \(t_2\) that is trusted by the owner (see Sections 6.2 and 6.3.1.2).

• Provided that \(t_1 \le t_2 \le t_1+d\), either the owner or the TTP shall assign the \(\mathit{assurance\_time}\) and the initial assurance level (see Sections 6.3.1.2 and 6.3.1.3).

The party who assigns the \(\mathit{assurance\_time}\) must know the value of \(d\), as well as the values of \(t_1\) and \(t_2\); the party who assigns the initial assurance level must also be aware of the method(s) used to determine \(t_1\) and \(t_2\).

• The owner shall record the \(\mathit{assurance\_time}\) and the initial level of assurance.

The owner shall:
a. Determine the appropriate value of \(d\). For example, \(d\) may be selected in accordance with the assurance of possession model described in Section 6.2, along with appropriate values of \(a\), \(b\) and \(c\).
b. Determine a trusted value for \(t_1\) (see Sections 6.2 and 6.3.2.1).
c. Perform one of the following:

• Determine a trusted value for \(t_2\) (see Sections 6.2 and 6.3.2.1).

• Provided that \(t_1 \le t_2 \le t_1+d\), assign and record the \(\mathit{assurance\_time}\) and the initial assurance level (see Sections 6.3.2.1 and 6.3.2.2).

a. Determine the appropriate value of \(d\). For example, \(d\) may be selected in accordance with the assurance of possession model described in Section 6.2, along with appropriate values of \(a\), \(b\) and \(c\).
If the TTP will be responsible for assigning the \(\mathit{assurance\_time}\), then the value of \(d\) shall be made known to the TTP.
b. The owner and/or the TTP shall determine a value for \(t_1\) that is trusted by the owner (see Sections 6.2 and 6.3.2.1).
c. The owner shall provide the owner’s currently-held keys to the trusted party, along with any other necessary data.
d. The TTP shall:

• The owner and/or the TTP shall determine a value for \(t_2\) that is trusted by the owner (see Sections 6.2 and 6.3.2.1).

• Provided that \(t_1 \le t_2 \le t_1+d\), either the owner or the TTP shall assign the \(\mathit{assurance\_time}\) and the initial assurance level (see Sections 6.3.2.1 and 6.3.2.2).

The party who assigns the \(\mathit{assurance\_time}\) must know the value of \(d\), as well as the values of \(t_1\) and \(t_2\); the party who assigns the initial assurance level must also be aware of the method(s) used to determine \(t_1\) and \(t_2\).

• The owner shall record the \(\mathit{assurance\_time}\) and the initial level of assurance.

a. Determine the appropriate value of \(d\). For example, \(d\) may be selected in accordance with the assurance of possession model described in Section 6.2, along with appropriate values of \(a\), \(b\) and \(c\).
b. The owner shall generate a new private-key-possession assurance message (see Section 6.3.1.1).
c. The owner shall sign the assurance message using the private key for which assurance is to be obtained, thus obtaining an assurance signature.
d. The owner shall provide the assurance message, the assurance signature and any other necessary data to the TTP.
e. The TTP shall determine a trusted value for \(t_1\) (see Sections 6.2 and 6.3.1.2).
f. The TTP shall verify the assurance signature using the public key that corresponds to the owner’s private key.
g. If verification is successful:

• The TTP shall determine a trusted value for \(t_2\) (see Sections 6.2 and 6.3.1.2).

• Provided that \(t_1 \le t_2 \le t_1+d\), the TTP shall assign the \(\mathit{assurance\_time}\) and the initial assurance level (see Sections 6.3.1.2 and 6.3.1.3).

• The TTP shall record the \(\mathit{assurance\_time}\), the initial assurance level, and the value of \(d\). These values should also be provided to the owner.

a. Determine the appropriate value of \(d\). For example, \(d\) may be selected in accordance with the assurance of possession model described in Section 6.2, along with appropriate values of \(a\), \(b\) and \(c\).
b. The owner shall provide the owner’s currently-held keys to the trusted party, along with any other necessary data.
c. The TTP shall determine a trusted value for \(t_1\) (see Sections 6.2 and 6.3.1.2).
d. The TTP shall:

• The TTP shall determine a trusted value for \(t_2\) (see Sections 6.2 and 6.3.1.2).

• Provided that \(t_1 \le t_2 \le t_1+d\), the TTP shall assign the \(\mathit{assurance\_time}\) and the initial assurance level (see Sections 6.3.2.1 and 6.3.2.2).

The TTP must know \(t_1\) and \(t_2\); the TTP must also be aware of the method(s) used to determine their values.

• The TTP shall record the \(\mathit{assurance\_time}\), the initial assurance level, and the value of \(d\). These values should also be provided to the owner.

The TTP shall provide both the recorded \(\mathit{assurance\_time}\) and the initial assurance level associated with the assurance of private key possession provided by the owner in response to a request by any relying party. In addition, the TTP may provide an assessment of its level of assurance that the owner is/was in possession of the private key at the time of the request for information (or any other time; see Sections 6.2 and 6.4).

Note that the values of \(a\), \(b\), \(c\) and \(d\) that are selected by the TTP may be different than the values deemed acceptable by other parties seeking assurance from the TTP. If this is the case, the third party should be prepared to (at least) provide an upper bound on the value of \(t_2 - t_1\) (e.g., \(d\)) to potential relying parties – as well as a description of the time sources used – so that those parties can decide whether or not a TTP-provided \(\mathit{assurance\_time}\) has sufficient accuracy (and trustworthiness) to meet their needs.

Assurance that the (claimed) signatory was in possession of the private key at the time the signature was generated shall be obtained by the verifier prior to accepting a verified digital signature as valid. The initial assurance of a (claimed) signatory’s possession of the private key shall be obtained by the verifier through interaction with either the (claimed) signatory or a TTP. However, once the necessary actions have been taken, the \(\mathit{assurance\_time}\) and the initial assurance level obtained may be used as the basis for obtaining assurance of private key possession by the same (claimed) signatory at other times (see Sections 6.2 and 6.4). A verifier shall obtain assurance that a (claimed) signatory possesses the correct private key using one or more of the following methods:

• The verifier shall determine a trusted value for \(t_2\) (see Sections 6.2 and 6.3.1.2).

• Provided that \(t_1 \le t_2 \le t_1+d\), the verifier shall assign the \(\mathit{assurance\_time}\) and the initial assurance level (see Sections 6.3.1.2 and 6.3.1.3).

• The verifier shall record the \(\mathit{assurance\_time}\) and the initial assurance level.

a. Determine the appropriate value of \(d\). For example, \(d\) may be selected in accordance with the assurance of possession model described in Section 6.2, along with appropriate values of \(a\), \(b\) and \(c\).
b. The verifier shall request assurance of the (claimed) signatory’s possession of its private signature key from a TTP.
If the TTP has obtained this assurance:
c. The TTP shall provide the method of obtaining the assurance, the recorded \(\mathit{assurance\_time}\), and an initial level of assurance of private key possession.
d. If requested by the verifier – the TTP should provide an upper bound on the value of \(t_2 - t_1\), a description of the method(s) used to obtain the times \(t_1\) and \(t_2\) (see Sections 6.3.1.2 and 6.3.2.1), and/or the TTP’s assessment of its level of assurance that the (claimed) signatory is/was in possession of the private key at the time of this request.
e. The verifier shall:

• (If provided by the TTP) reject the TTP-provided assurance if the upper bound on \(t_2 - t_1 > d\); otherwise,

• Record the \(\mathit{assurance\_time}\) and the initial assurance level provided by the TTP, and/or

• (If provided by the TTP) use the description of the method(s) used to obtain the times \(t_1\) and \(t_2\) to determine whether or not to adjust the TTP-provided assurance level(s) (see Sections 6.2, 6.3.1.3 and 6.3.2.1).

A nonce supplied by the intended verifier. If this option is used, the nonce shall contain a random component with entropy equal to or greater than the security strength associated with the private key for which assurance of possession is sought. If the assurance message will not include a TST, and the relying parties require that an \(\mathit{assurance\_time}\) be recorded upon successful verification of the assurance signature, then the nonce should also contain a verifier-supplied timestamp component that unambiguously represents the time that the nonce was made available for inclusion in the assurance message.