# Presentation: 346398

## WG5 

- Recap
- Requirements
- Issues

## Recap

- Key Recovery Classifications
-  private key recovery (PK or Symmetric)
-  session key recovery
- Protocol Classifications
-  transaction-based -- SMIME, MOSS, SHTTP
-  session-based -- SSL, Voice

## Recap Continued

- Interoperability Components
-  Key Recovery Requestor
-  Key Recovery Agent
-  Key Recovery Medium
-  Data Recovery Medium

## Interoperability Requirement #1

- There shall be a well-defined mapping from each component of the model to the implementation seeking certification
- Interoperability certification shall be determined through the interactions between the system components as defined by this mapping.

## Interoperability Requirement #2

- Interoperable protocols that incorporate a FIPS-compliant key-recovery mechanism must remain interoperable.
- In order to be effective, users of FIPS compliant implementations for the same protocol must have assurance that these implementations will interoperate.

## Interoperability Requirement #3

- Multiple techniques for key recovery shall be supported.
- These will include both private key and session key recovery schemes.

## Interoperability Requirement #4

- Receiver verification is desirable, but shall not be required for compliance.
- verification may be dependent upon the KR mechanism used.
- single verification method may disallow some KR methods.
- Recipient may not be able to determine the KRA of the originator.

## Interoperability Requirement #5

- When possible, the addition of compliant key recovery shall not affect interoperability with non-recoverable implementations.
- To promote the use of FIPS compliant implementations, it is desirable for compliant implementations to interoperate with the existing installed base.

## Interoperability Requirement #6

- Signature key recovery may be a feature of systems implementing private key backup, but shall not be required for FIPS compliance.
- Signature key recovery is not within the scope or intent of this standard.

## Interoperability Requirement #7

- Compliant systems which implement private key recovery shall not  affect protocol interoperability.
- Such systems may optionally specify a KRA in the user certificate.
- As long as the originator is not required to retain the ability to subsequently decipher traffic, there are no interoperability issues.

## Interoperability Requirement #8

- Electronic key recovery requests shall be supported.
- These requests shall be cryptographically secured with an assurance commensurate with the cryptosystem being recovered.

## Interoperability Requirement #9

- An algorithm-independent secure MIME format shall be utilized for KRR to KRA exchanges.
- As long as there is no ambiguity, multiple MIME formats may be concurrently supported.
- E.g. MOSS, S/MIME & PGP-MIME.

## Interoperability Requirement #10

- The KR request message containing the subject key recovery field and/or encrypted data shall be both digitally signed and encrypted.
- These services shall be applied to the KRR message to prevent forgery, or manipulation of KRR data, as well as providing auditability for KR requests.

## Interoperability Requirement #11

- The recovery request itself shall utilize a FIPS-compliant key recovery system.
- To provide a means to monitor rogue KRR’s and/or KRA’s it is necessary to incorporate compliant mechanisms for KRR to KRA communications.

## Issue

- Vendor-Specific Protocols
- Although the addition of  key recovery to a non-standard protocol should ideally maintain interoperability, the associated design decisions are assumed to be the purview of the individual  product vendors.
- Which protocol interoperability requirements are appropriate for these protocols?