fips171.txt

《应用密码学》协议、算法与C原程序(第二版)配套源码。很多人都需要的

                    count       technique     provides
                    window      of Appendix   interoperability
                                F of ANSI
                                X9.17 is
                                mandatory
                           APPENDIX A
                   ANSI X9.17 INTERPRETATIONS


Ambiguities and inconsistencies have been noted in ANSI X9.17
during the implementation of the standard.  The following items
contain interpretations of the standard which have been made.  The
requirements for Federal Government use appear in underlined bold
face type.
 
 
A.1    SENDING AN ESM IN RESPONSE TO AN RSM SENT IN RESPONSE TO A
       DSM. 

       Problem:
       The standard explicitly states that "when an RSM [sent in
       response to a DSM] is received in error, no ESM shall be
       sent, and manual recovery procedures are required".  In
       addition, the figures which depict message flow with errors
       do not show an ESM in response to an RSM to a DSM 
 
       However, the description in the processing of an RSM
       contradicts this and implies that an ESM to an RSM to a DSM
       is required.  In particular, it states that "If an IDD
       field is present, this RSM is in response to a DSM ... If
       the IDD does not match one of the IDD fields sent in the
       DSM to which this RSM responds, this shall cause processing
       of the RSM to cease and the generation and transmission to
       the originating party of an ESM with an "I" in the ERF
       field. I.e., ERF/I." 
 
       Interpretation
       The first statement is considered to be the appropriate
       action, i.e., an ESM shall not be sent in response to an
       RSM which responds to a DSM. An error found in the RSM to
       a DSM should cause processing of the RSM to cease, and
       manual recovery procedures should be used to resolve the
       discrepancy. 


A.2    THE USE OF NAMED AND UNNAMED KEYS 

       Problem:
       The standard specifies that a key may be unnamed if it is
       the only key of that type shared between two parties or
       between a party and a center .  The standard does not
       forbid naming a key even if it is the only key of that type
       shared.  The combination of these two facts implies that if
       one and only one key of a particular type is shared, then
       that key may or may not be named; and that if more than one
       key of a particular type is shared, then all such keys must
       be named. 

       In addition, there are numerous statements in the standard
       which specify that the key name need not be used in key
       identifier subfields if it is the only key of that type
       shared. 
 
       The following difficulties arise: 
 
       o            What is the appropriate action when several
                    keys of a particular type are shared (and
                    hence named), and a KSM is received containing
                    a single unnamed key of the same type? 
 
       o            How should a party respond when a single key
                    of a particular type is shared, the key is
                    unnamed, and a KSM is received containing a
                    named key of the same type? 
 
       o            If a key of a particular type has a name, but
                    it is the only one shared, should the name be
                    used in the key identity subfields of a KSM or
                    in the IDD or IDA fields of DSMs, and RSMs
                    which respond to DSMs? 
 
       o            When the standard discusses actions which may
                    be taken if the key is the only key of that
                    type shared, does this mean that the key is
                    the only key of that type that may ever be
                    shared (e.g., there is storage for only one
                    key of that type), or does it mean that there
                    is only one key of that type that is currently
                    shared (i.e., more keys may have been shared
                    previously or may be shared in the future)? 
 
       Interpretation:
       The parties to a key exchange must have a prior bi-lateral
       agreement to name keys or not to name them.  Once such an
       agreement is made, a change from naming to not naming (or
       the converse) cannot be made without changing the
       underlying agreement concerning the keying relationship. 
       If key(s) are received in violation of this agreement, an
       ESM should be returned with a "C" (cannot process) in the
       ERF field.  In particular, if two parties share one or more
       named keys and an unnamed key is received, the recipient
       shall return an ESM with a "C" in the ERF field.  If two
       parties share one unnamed key and a named key is received,
       the recipient should return an ESM with a "C" in the ERF
       field. 
 
       In addition, when keys are named, the names should always
       be used.  Refer to Option 6.


A.3    DISCONTINUING VERSUS REPLACING KEYS. 

       Problem:
       The standard states that "when a (*)KK is discontinued, all
       keys sent encrypted under that (*)KK shall also be
       discontinued without being named in the DSM".  This may
       be implemented by maintaining a linkage between the higher
       level (*)KK and the (*)KKs and KDs encrypted by it. 
       However, when a manually or automatically distributed (*)KK
       is replaced by a new (*)KK of the same name, it is not
       clear whether or not all other (*)KK's and KD's distributed
       (encrypted) by the original (*)KK should be discontinued.

       Interpretation:
       When a (*)KK is replaced (as opposed to discontinued) then
       only that (*)KK shall be affected, and other keys which may
       have been encrypted by that (*)KK should not be affected. 
       A "linkage" shall be made between the new (*)KK and the
       keys encrypted by the replaced (*)KK, so that if a
       compromise of the replaced (*)KK is later discovered, all
       keys encrypted by the replaced (*)KK can easily be
       identified and discontinued. 


A.4    ARCHIVING OF KEYS

       Problem:
       Section 3.6.3 discusses the archiving of keys, but does not
       state that archiving MUST be done or suggest when it should
       be done. However, it is a good business practice to archive
       a discontinued key if the key may be needed later.  Should
       replaced keys also be archived?

       Interpretation:
       Replacing a key by a new key with the same name 
       effectively discontinues the original key, and the key
       should, therefore, be archived. The archiving of keys in
       any system is regarded as good accounting practice.  The
       transactions may have to be reconstructed at a later date
       to verify that the correct action was taken.
 
A.5    DELAYS BETWEEN THE SENDING OF AN RSM TO A KSM AND THE
       RECEIPT OF A RESPONSE 

       Problem:
       If an RSM is sent in response to a KSM, either an ESM
       response is expected or no response is expected.  The
       standard does not address the time interval to wait until
       it is known that the RSM was received successfully.
 
       Interpretation:
       This is outside the scope of ANSI X9.17.  However, this
       problem does not occur if, upon correct receipt of the RSM,
       the sender of the KSM immediately sends valid data
       protected using the data keys sent in the KSM.  Receipt of
       that data and its subsequent successful authentication or
       decryption provides a positive acknowledgement that the RSM
       was received correctly. 


A.6    CONFUSION ABOUT THE UNIQUE IDENTIFICATION OF DATA KEYS

       Problem:
       The standard never explicitly states how keys are to be
       uniquely identified.  At first, it appears that keys can be
       uniquely identified by their sharing party, key identifier,
       and key type ((*)KK or KD).  However, the standard
       explicitly states that "Two data keys with the same name
       may be sent in the same message". Unless otherwise
       determined by prior agreement, if two KDs are sent in the
       same message, the first KD shall be used by the ultimate
       recipient for authentication; the second shall be used for
       encryption".  Therefore, KDs may be identified not only
       by the sharing party, key identifier, and type (KD), but
       also by a subtype (authentication or encryption). 
 
       Interpretation
       (*)KKs may be uniquely identified by their sharing party,
       key identifier and their type (i.e., key encrypting key).
       KDs may be identified by their sharing party, key identity,
       their type (data key) and their subtype (data key for
       authentication or data key for encryption).



A.7    KD REPLACEMENT CONFUSION

       Problem:
       When two data keys are sent in the same message, the first
       is designated as an authentication key; the second as an
       encryption key. If a KSM is received with two KDs having
       distinct identifiers, the first KD (say, KDX) is an
       authentication key, and the second KD (say, KDY) is an
       encryption key.  If another KSM is received using the same
       two distinct KD identifiers, but the key with identifier
       KDY is first and the key with identifier KDX is second, it
       is unclear whether the new KDY (an authentication key)
       replaces the old KDY (an encryption key), or if this
       situation is illegal. The same goes for the replacement of
       the old KDX (an authentication key) by the new KDX (an
       encryption key).

       Interpretation:
       The new KDY (an authentication key) replaces the old KDY
       (an encryption key), and the new KDX (an encryption key)
       replaces the old KDX (an authentication key). Section 6.4
       states that "all stored keys of the same type (key
       encrypting keys or data keys) with the same name shall be
       replaced".
 

A.8    IMPLICIT DESIGNATION OF THE USE OF A DATA KEY FOR
       AUTHENTICATION OR ENCRYPTION. 

       Problem:
       The standard states that "A data key can be used for either
       encryption or authentication but not both, except for a
       Cryptographic Service Message".  This is interpreted to
       mean that this stipulation applies to the entire
       cryptoperiod of the key, not just for a single message. 
       I.e., once a key is used for authentication of one message,
       it can never be used as an encryption key, and conversely,
       once a key is used as an encryption key, it can never be
       used as an authentication key.

       The standard does not designate the purpose of a single KD
       field in a message. However, if an IV accompanies that KD,
       the KD could be considered to be an encryption key.  If the
       single KD is not accompanied by an IV, the designation as
       an authentication or encryption key is not known.

       Interpretation:
       When one KD is sent in a message, the first use of that KD
       after it is sent in a CSM shall determine its use for the
       remainder of the key's cryptoperiod unless a bilateral
       agreement states otherwise.
 

A.9    TERMINATION OF A KEYING RELATIONSHIP UPON THE RECEIPT OF A
       DSM CONTAINING A NULL IDD FIELD

       Problem:
       The standard indicates that an empty IDD field in a DSM
       means that the entire keying relationship should be
       terminated. However, the standard never explicitly states
       what the entire relationship is.

       Interpretation:
       The keying relationship consists of all manually and
       automatically distributed keys and IVs shared with the
       other party. The keying relationship is terminated (i.e.,
       all keys and IVs are deleted) if the DSM contains either a
       single NULL IDD field, or several IDD fields, one or more
       of which are NULL. Resumption of the keying relationship
       will then require a redistribution of manual keys, or, in
       the case of a center environment, utilization of the center
       to re-establish a keying relationship.

       Note that in generating the RSM to the DSM, the IDD fields
       must be copied from the DSM to the RSM. This is
       interpretated to mean that the fields are copied in the
       order in which they were received in the DSM.


A.10   RECEIPT OF AN RSI WHICH REQUESTS A *KK TO BE SENT WHEN ONLY
       A MANUALLY DISTRIBUTED KK IS SHARED 

       Problem:
       If an RSI is received with a *KK in the SVR field, but only
       a single manually distributed KK is shared, there is no
       error identified to return in an ESM. In fact, in Section
       10.7 on processing an RSI message, the SVR field is not
       even checked.

       Interpretation:
       The SVR field of an RSI must be checked for appropriate
       requests, including the presence of a *KK request when only
       a KK is shared, as well as a request for both a KK and a
       *KK.  An error code of "C" shall be returned in the ERF
       field of an ESM when an error of this type is detected.
 

A.11   PROCESSING A MISROUTED CSM

       Problem:
       The standard indicates that if the party identified in the
       RCV field of a received CSM is not the party processing the
       CSM, then the message has been misrouted and shall not be
       processed further. The standard does not discuss the
       ha