5.2 Interchange Keys (IKs) (original) (raw)

Connected: An Internet Encyclopedia
5.2 Interchange Keys (IKs)

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1421
Up: 5. Key Management

Prev: 5.1 Data Encrypting Keys (DEKs)
Next: 5.2.1 Subfield Definitions

5.2 Interchange Keys (IKs)

Interchange Key (IK) components are used to encrypt DEKs and MICs. In general, IK granularity is at the pairwise per-user level except for mail sent to address lists comprising multiple users. In order for two principals to engage in a useful exchange of PEM using conventional cryptography, they must first possess common IK components (when symmetric key management is used) or complementary IK components (when asymmetric key management is used). When symmetric cryptography is used, the IK consists of a single component, used to encrypt both DEKs and MICs. When asymmetric cryptography is used, a recipient's public component is used as an IK to encrypt DEKs (a transformation invertible only by a recipient possessing the corresponding private component), and the originator's private component is used to encrypt MICs (a transformation invertible by all recipients, since the originator's certificate provides all recipients with the public component required to perform MIC validation.

This RFC does not prescribe the means by which interchange keys are made available to appropriate parties; such means may be centralized (e.g., via key management servers) or decentralized (e.g., via pairwise agreement and direct distribution among users). In any case, any given IK component is associated with a responsible Issuing Authority (IA). When certificate-based asymmetric key management, as discussed in RFC [1422, is employed, the IA function is performed by a Certification Authority (CA).

When an IA generates and distributes an IK component, associated control information is provided to direct how it is to be used. In order to select the appropriate IK(s) to use in message encryption, an originator must retain a correspondence between IK components and the recipients with which they are associated. Expiration date information must also be retained, in order that cached entries may be invalidated and replaced as appropriate.

Since a message may be sent with multiple IK components identified, corresponding to multiple intended recipients, each recipient's UA must be able to determine that recipient's intended IK component. Moreover, if no corresponding IK component is available in the recipient's database when a message arrives, the recipient must be able to identify the required IK component and identify that IK component's associated IA. Note that different IKs may be used for different messages between a pair of communicants. Consider, for example, one message sent from A to B and another message sent (using the IK-per-list method) from A to a mailing list of which B is a member. The first message would use IK components associated individually with A and B, but the second would use an IK component shared among list members.

When a PEM message is transmitted, an indication of the IK components used for DEK and MIC encryption must be included. To this end, Originator-ID and Recipient-ID encapsulated header fields provide (some or all of) the following data:

Identification of the relevant Issuing Authority (IA subfield)
Identification of an entity with which a particular IK component is associated (Entity Identifier or EI subfield)
Version/Expiration subfield

In the asymmetric case, all necessary information associated with an originator can be acquired by processing the certificate carried in an "Originator-Certificate:" field; to avoid redundancy in this case, no "Originator-ID-Asymmetric:" field is included if a corresponding "Originator-Certificate:" appears.

The comma character (",") is used to delimit the subfields within an Originator-ID or Recipient-ID. The IA, EI, and version/expiration subfields are generated from a restricted character set, as prescribed by the following BNF (using notation as defined in RFC 822, Sections 2 and 3.3):

IKsubfld := 1*ia-char

ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" / "." / "/" / "=" / "?" / "-" / "@" / "%" / "!" / '"' / "_" / "<" / ">"

An example Recipient-ID field for the symmetric case is as follows:

Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,2

This example field indicates that IA "ptf-kmc" has issued an IK component for use on messages sent to "linn@zendia.enet.dec.com", and that the IA has provided the number 2 as a version indicator for that IK component.

An example Recipient-ID field for the asymmetric case is as follows:

Recipient-ID-Asymmetric: MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,66

This example field includes the printably encoded BER representation of a certificate's issuer distinguished name, along with the certificate serial number 66 as assigned by that issuer.

Next: 5.2.1 Subfield Definitions

Connected: An Internet Encyclopedia
5.2 Interchange Keys (IKs)