Interoperability Requirements This FIPS establishes interoperability requirements for several types of key recovery system components: end user systems (System A and B), Key Recovery Agents, and Key Recovery Requestors. No interoperability requirements are imposed on supporting (ancillary) components, nor are interoperability requirements imposed on communication between an end user system and a key recovery agent. In both cases the imposition of interoperability requirements is viewed as potentially too restrictive, in light of the wide range of key recovery technologies that the FIPS attempts to embrace. This FIPS defines a syntax for communication between a KRR and a KRA. This syntax applies only to electronic key recovery transactions effected via a communication medium, e.g., telephone, LAN, Internet, etc. Recovery transactions effected via storage media (e.g., diskette, tape, etc.) or via direct interaction (e.g., self recovery on a PC) are not covered by these requirements. These syntactic requirements has been established to reduce life cycle costs for users of key recovery systems and because it appears to be feasible to do so without introducing undue constraints on technology options. Section ?? defines the syntax for this communication syntax. No interoperability requirements are imposed on communication among KRAs from different vendors. Interoperability requirements for end-user systems apply only to the use of key recovery for communicated data, not for data storage. With regard to such systems (System A and B, where A and B are distinct), interoperability requirements apply only in the context of systems that communicate in an interoperable, encrypted fashion exclusive of the use of key recovery technology. Such systems fall into two categories: those that make use of "standard" communication protocols and those that make use of "proprietary" protocols. (For purposes of this FIPS, the phrase "standard communication protocol" encompasses any communication protocol adopted by a generally recognized protocol standards organization, including the ITU, ANSI, IEEE, the ATM Forum, and the IETF.) No interoperability requirements are established for end-user systems based on proprietary communication protocols. Such systems typically exhibit limited interoperability (across vendor product lines) due to the use of non-standard protocols. Vendors are encouraged to embody key recovery technology in their products in a fashion that minimizes disruption to the installed product base, i.e., to facilitate communication between key recovery aware and key recovery unaware products. When key recovery is introduced into a system using a standard (encryption) communication protocol, it must be done in a fashion that preserves interoperability. Interoperability is required when communicating with other key recovery-aware/enabled systems, and when communication with non-aware and non-enabled systems. (Some recovery-aware'enabled systems may be configured so that they will refuse to communicate with other systems unless it can be determined that the other systems are employing key recovery. If this feature is activated, it may prevent interoperability between otherwise interoperable systems. However, the presence of this configurable feature does not exempt a system from meeting the interoperability requirements detailed below.) There are two general approaches to meeting this requirement. If a private key recovery scheme is employed, the (extant) secure communication protocol employed by the end-user systems need not be modified to carry any key recovery information, and thus interoperability is preserved. Note that in this case interoperability is preserved both among recovery-aware/enabled systems and between aware/enabled systems and non-aware/enabled systems. If no changes are made to the secure communication protocol, including supporting key/certificate management protocols, then it may or may not be possible for communicating systems to determine if key recovery is being employed. If a private key escrow scheme elects to transmit some information in a secure communication protocol to indicate that key recovery is enabled, then it must do so in a fashion that does not affect interoperability. For example, if X.509 public key certificates are employed to support secure communication, an extension could be added to each certificate specifying the KRA for! the subject. If such an extension were employed, and not marked "critical," this would comply with the interoperability requirement established here. If a session key recovery scheme is employed, then key recovery information is carried in the secure communication protocol. In some standard, secure communication protocols it is possible to carry this information in a fashion that preserves interoperability, without modifying the protocol. For example, in a secure e-mail protocol (e.g., MSP, PGP, S/MIME, X.411) an additional recipient, representing a KRA, could be added to the per-recipient token list to provide for key recovery on a per message basis. In ISAKMP, a participant in the key management exchange could generate and transmit a NOTIFY message with a payload containing per-session key recovery information. Even though no standard format for such a NOTIFY payload has been defined, a compliant implementation is required to silently discard an unrecognized payload and thus this technique preserves interoperability. Both of these approaches to providing key recovery would be compliant with the interoperability requ! iremen ts established here. If it is necessary to transport key recovery information and there is no provision in a standard communication protocol for doing so in an interoperable fashion, then it will be necessary to modify/extend the protocol to carry such information. It is outside the scope of this FIPS to specify how key recovery information shall be transported in the context of such protocols. The definition of interoperable means of carrying such information is solely the purview of the cognizant standards body for each affected protocol. Thus a vendor of an end system product in this category must provide documentation demonstrating that the product transports key recovery information in a fashion consistent with the specification developed and adopted by the cognizant standards body for the protocol in question. Only then can an end system key recovery product be considered compliant with this interoperability requirement. (If we want to facilitate interoperability among KR-enabled implementations that insist on checking to see if KR is in use by the other end, it is in this section that we would add a further requirement to employ a specific format as a wrapper for such data. We must decide if we want to make that a requirement, or just provide a recommended format in an appendix. Also, we can decide to provide an X.509 extension, either as a recommended format or as THE way to do this IF you use X.509. Again, the benefit to defining THE format is to promote the next level of interoperability, for interceptors and for implementations that want to check. Also, because it is OK for ANYONE to define new extensions, it IS within the purview of the TAC to do so. So, what say ye?) KRA-KRR Interoperability Requirements (to be supplied by WG 5)