# Secretary's Comment: Following the February TAC meeting, TAC Member Dr. Josh Benaloh distributed a discussion paper identifying nine major issues, seeking input from the federal liaisons. Since then, the Government Liaisons met to discuss these issues and developed responses prior to the April TAC meeting. The issues and government responses (with brief accompanying rationale) are presented below

# Government Liaison Responses to TAC Discussion Items

1.  Default Operation of Key Recovery.

> As yet, we have no text to cover this, although it is related to
> 2.2.1.5. The issue is whether a minimally compliant (Level 1)
> FIPS-compliant end-user device should be required to have key recovery
> active unless (when possible) explicitly de-activated? If the answer
> to this is to be "yes", appropriate wording will be necessary to
> capture this requirement.
>
> The product must have a capability to activate/deactivate key recovery
> functions by a system administrator to allow implementation of an
> organizational policy.
>
> (There is no explicit requirement for the default status of the key
> recovery function.)

2.  System Administrator Functions.

### Do we want to create a system administrator role? Possible functions of a system administrator might include the enabling and disabling of user control of key recovery operation and the setting of configuration options and defaults. In some cases, the granularity may be quite fine -- for example, a system administrator may wish to require that end-users activate key recovery for stored data but give users the option as to whether or not to activate key recovery for communications. If we decide to create this role, we must decide whether or not this role is to be mandatory and what functions *must* be provided for this role and what functions *may* be provided for this role.

> Text for the system administrator role would presumably be included in
> section 2.2.1 and perhaps 2.2.2. Possible wording could be of the
> form, "The end-user product shall/may provide the capability for the
> system administrator to {activate \| disable \| set a default \| leave
> up to user} use of key recovery for {stored \| real-time communicated
> \| store-and-forward} data. In the extreme, there may be twelve
> distinct clauses of the above form and for each we must decide whether
> to include with "shall", include with "may", or omit.

Create a mandatory System Administrator role within the FIPS for
end-user products and define the responsibilities of the role. (Some
System Administrator functions are defined with the WG2 draft.)

> ***This role provides the ability for an organization to control key
> recovery functions and facilitates higher assurance by creating
> separate roles and responsibilities within the system. Most Government
> systems are networked, but in small or single user PC-based systems,
> the user can hold dual roles. This should be addressed in the
> Implementation Guidance.***

3.  FIPS 140-1 level 2 compliance for Key Recovery Agents.

### Do we wish to require of key recovery agents that (section 2.1.1.1.1) "All cryptographic modules shall be FIPS 140-1 Level 2 or higher compliant"?

***YES.***

> ***Maintain requirement for FIPS 140-1 Level 2 for a Level 1 Key
> Recovery Agent. Maintain requirement for FIPS 140-1 Level 3 for a
> Level 2 Key Recovery Agent.***
>
> ***The FIPS 140-1 requirement is for the cryptographic module only. In
> a purely software solution, the cryptographic module may include the
> operating system. In other systems, it is a hardware device, e.g. a
> FORTEZZA card, with no operating system components.***
>
> ***Level 2 features address some of the vulnerabilities found at the
> Key Recovery Agent by requiring additional access control and
> authentication measures and providing for additional physical security
> measures. FIPS 140-1 Level 2 requirements are consistent with the
> additional Key Recovery Agent security requirements, e.g. role-based
> authentication features for role separation. For a higher assurance
> Key Recovery Agent, FIPS 140-1 will provide for additional physical
> security measures. There are many scenarios where government users
> will have requirements for higher assurance.***

***Summary of FIPS 140-1 Levels***

***Level 1 -- Basic security requirements***

> ***Level 2 -- improves the physical security requirements by adding
> tamper evident coating or seals***

***- Requires role based authentication***

> ***- Requires a C2 operating system for software cryptographic
> modules***
>
> ***Level 3 - additional physical security requirement to prevent
> physical access to the module***
>
> ***- Requires identity based authentication***
>
> ***- Requires a B1 operating system for software cryptographic
> modules***

4.  Partial Compliance.

> Do we wish to allow products that provide *some* key recovery
> functionality that is not compliant with the FIPS to obtain FIPS
> certification for its compliant functionality? The example discussed
> was that of an integrated software product that is FIPS 140-1 Level 1
> compliant and provides FIPS compliant end-user key recovery
> functionality as well as key recovery agent functionality for
> self-escrow or private enterprise uses. It might be possible for such
> a product to, when used with a product that provides FIPS-compliant
> key recovery agent functionality, form a suitable FIPS system. Said
> another way, should the inclusion of non-compliant key recovery agent
> functionality in an otherwise compliant product make the product
> ineligible for FIPS certification?
>
> ***All key recovery functions contained in a Commercial-Off-the Shelf
> product must have the ability to be configured in the FIPS compliant
> mode.***
>
> ***A product containing non-compliant key recovery functions could be
> still FIPS certified if compliant modes of those key recovery
> functions are available in the product.***

5\. Interoperability

### Is it to be a requirement that all FIPS compliant key recovery systems are able to interoperate with each other? Should there be switches that allow a compliant end-user product to refuse to communicate with a non-compliant end-user product? If so, are these switches to be mandatory? If so, at what levels? Are they to be under system administrator control? Should there be switches to activate warnings when communicating with a non-compliant product (or a compliant product with key recovery disabled or a compliant product with key recovery activated)? If so, should these switches be mandatory and at what level and under whose control?

> No constraints are placed on the interoperability between FIPS
> compliant and FIPS non-compliant systems. This will be a
> market-driven, product-by-product decision.

6.  Binding Recovery Information to Encrypted Communications

> Currently section 2.2.1.4.3 requires that end-user products be capable
> of "secure binding" of key recovery information to encrypted
> communications. Is this desirable? If so, how do we define strong
> binding?
>
> Change the wording in 2.2.1.4.3 to "secure association" of the key
> recovery information to the encrypted data. This allows implicit
> association of key recovery information to the data for encapsulation
> techniques. The use of the word "secure" is intended to express a
> requirement for some level of assurance in the association mechanism.
> (This will require some additional definition to be testable.)
>
> In a March session with several industry representatives, there was a
> discussion of acceptable methods of binding or associating the key
> recovery information with the encrypted data. They noted that for an
> escrow scheme, it was acceptable to indicate the location of the key
> recovery information in the certificate. This is an implicit binding
> or association. For encapsulation, similar implicit techniques should
> also be acceptable. This could mean that a pointer to the key recovery
> information (e.g. KRB) would be sent with the data, and that the
> corresponding key recovery information or KRB would contain a pointer
> back to the encrypted data.

7.  Key Recovery Information Validation

> Currently section 2.2.1.4.4 requires compliant end-user products to be
> capable of validating key recovery information. Do we want to keep
> this? If so, at what level? Do we want to specify and require a common
> key recovery block format? Do we want to specify and require an
> attribute certificate format? If an attribute certificate is to be
> required, what requirements are to be placed on certification
> authorities?

Maintain requirement for compliant end-user products to validate Key
Recovery Information.

Key Recovery Information Validation is an integrity check on the key
recovery information. This is contained in requirement 2.2.1.4.1 and
2.5.1.3.1

At the February meeting, it was agreed that requirement 2.2.1.4.4
requiring source authentication was to be removed. It was removed in the
revised WG 2 draft distributed in February. In order to facilitate
integrity checking on key recovery information, we should require a
common key recovery block format for encapsulation schemes. (see WG1
work). For escrow schemes, we should define an X.509 extension for key
recovery and require its use.

8.  Recoverability of KRR to KRA Transactions.

> Do we wish to specify recoverability requirements for transactions
> between key recovery requestors and key recovery agents? If so
> (recalling that both KRRs and KRAs are currently required to be FIPS
> 140-1 Level 2 compliant), what features are required? Must KRRs and
> KRAs have all of the features and meet all of the requirements of
> Level 2 end-user systems?

We should not specify recovery requirements for KRA-KRR communications,
as long as there is a standardized, strictly enforced format for these
communications.

End User Products with an embedded KRR function for requesting keys for
their own recovery should be required to implement a KRR that is FIPS
140-1 Level 1 or higher. If the Key Recovery Request is used for
requesting keys for multiple users, then the KRR should be a FIPS 140-1
Level 2 or higher.

9.  Receiver Verification.

> What (if any) requirements do we wish to place on verification of
> receivers of communication? Do we wish FIPS compliant end-user
> products to be capable of receiver verification? If so, at what level?
> Should there be switches and, if so, under whose control? How is
> verification handled when multiple key recovery methods are supported?
> Is receiver verification compatible with multi-casting?
>
> No requirements for receiver verification for Level 1 end-user
> products. For Level 2, require end-user products to perform receiver
> verification if communicating with a similar product using the same
> key recovery mechanism.
>
> Receiver verification is the function of having the end-user product
> verify that the key recovery information will actually decrypt the
> encrypted data. This requirement is currently contained in 2.5.2.3.1
> under a Level 2 High Assurance Key Recovery Information Validator. KRI
> Validation provides an assurance that the encrypted information can be
> recovered. It also counters the threat of a single user substituting
> key recovery information without the second party's knowledge.
> However, it also decreases potential interoperability between systems
> using different key recovery techniques.