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):
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:
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.
