Consider a situation where two parties communicate encrypted contents each other. There are some scenarios as follows:
In the first case, reference directions (i.e., content-encryption keys to encrypted contents or the reverse) are not serious because both are in the same package. In the second case, contents encrypted with certain content-encryption keys should reference them because an originator encrypts contents with content-encryption keys held by specific recipients. In the last case, contrarily, content-encryption keys should reference contents encrypted with them because a recipient who has certain content-encryption keys tries to get contents encrypted with them. Considering these scenarios, content-encryption keys and contents encrypted with them should be able to reference each other.
Also there is the following scenario:
[PROP1] is based on [CMS] and it has two formats for enveloped contents and directly encrypted contents. Both formats should be merged into one format because this scenario requires them at the same time.
The information relative to encryption keys includes their locations, encrypted contents' locations, encryption algorithms, and so on. Such information is contained in the EncryptionInfo element, which has the following structure (where "?" denotes zero or one occurrence; "+", one or more occurrences; and "*", zero or more occurrences, while "|" denotes alternatives):
<EncryptionInfo (Id=)?>
<SingleKeyEncryptionInfo>
(KeyInfo)
|(KeyAgreement)
|(KeySharing)
(EncryptionMethod)
(EncryptionPropertyList)?
</SingleKeyEncryptionInfo>
|<MultipleKeysEncryptionInfo>
<SingleKeyEncryptionInfoList>
(SingleKeyEncryptionInfo)+
</SingleKeyEncryptionInfoList>
(ApplicationMethod)
(ApplicationPropertyList)?
</MultipleKeysEncryptionInfo>
(Reference (URI=)? (XPath=)?)*
</EncryptionInfo>
|
Principal elements includes the following:
When encrypting contents with a symmetric key shared with recipients, an EncryptionInfo element will be as follows:
[01] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="encryptionInfo23"> [02] <SingleKeyEncryptionInfo> [03] <KeyInfo> [04] <KeyName>1234</KeyName> <!-- Symmetric key identifier --> [05] </KeyInfo> [06] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#des-cbc-pkcs5padding" /> [07] </SingleKeyEncryptionInfo> [08] </EncryptionInfo> |
[01-08] The EncryptionInfo element may reference one or more encrypted contents, and reversely may be referenced by them. This element is the latter because it specifies the Id attribute, which is used for being referenced.
[02-07] When encrypting contents with a single key, the SingleKeyEncryptionInfo element should be used. The element contains an encryption key, an encryption algorithm, and optional meta-information relative to encryption.
[03-05] One KeyInfo element corresponds to one encryption key. The element has the almost same structure and semantics as in [DSIG].
[04] The KeyName element contains a string value that may be used by the originator to communicate a key identifier to recipients.
When encrypting contents with a recipient's public key directly, an EncryptionInfo element will be as follows:
[01] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc"> [02] <SingleKeyEncryptionInfo> [03] <KeyInfo> [04] <X509Data> <!-- Recipient's certificate --> [05] <X509IssuerSerial> [06] <X509Issuer>ABC CA</X509Issuer> [07] <X509Serial>12345678</X509Serial> [08] </X509IssuerAndSerial> [09] </X509Data> [10] </KeyInfo> [11] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#rsa" /> [12] </SingleKeyEncryptionInfo> [13] <Reference URI="#encryptedData11" /> [14] <Reference XPath="//EncryptedData" /> [15] </EncryptionInfo> |
[01-15] This is the element that references one or more encrypted contents, and uses two Reference elements for them.
[04-09] The X509Data element contains one or more identifiers of a recipient's X.509 certificate or the certificate itself. The X509IssuerSerial element contains an issuer's distinguished name/serial number pair.
[13-14] One Reference element corresponds to one encrypted content. The element uses the URI and/or XPath attributes for specifying the content.
When encrypting contents with a randomly generated symmetric key and delivering the key by key transport, an EncryptionInfo element will be as follows:
[01] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="encryptionInfo23"> [02] <SingleKeyEncryptionInfo> [03] <KeyInfo> [04] <EncryptedKeyValue URI="#encryptionInfo27">k0xFFH56...</EncryptedKeyValue> [05] <EncryptedKeyValue> [06] <EncryptionInfo> [07] <EncryptionInfoItem> [08] <KeyInfo> [09] <X509Data>...</X509Data> <!-- Recipient B's certificate --> [10] </KeyInfo> [11] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#rsa" /> [12] </EncryptionInfoItem> [13] </EncryptionInfo> [14] a9Lkj2nd... <!-- Encrypted key value --> [15] </EncryptedKeyValue> [16] </KeyInfo> [17] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#des-cbc-pkcs5padding" /> [18] </SingleKeyEncryptionInfo> [19] </EncryptionInfo> [20] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="encryptionInfo27"> [21] <SingleKeyEncryptionInfo> [22] <KeyInfo> [23] <X509Data>...</X509Data> <!-- Recipient A's certificate --> [24] </KeyInfo> [25] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#rsa" /> [26] </SingleKeyEncryptionInfo> [27] </EncryptionInfo> |
[03-16] When using key transport, the KeyInfo element contains a symmetric key encrypted with each recipient's public key in parallel. One EncryptedKeyValue element is used for containing one encrypted key.
[04] This element contains the symmetric key encrypted with recipient A's public key, and uses the URI attribute for referencing an EncryptionInfo element containing a certificate of the public key.
[05-15] This element contains the symmetric key encrypted with recipient B's public key. It also contains an EncryptionInfo element just before the encrypted key value.
When encrypting contents with a pairwise symmetric key generated from the originator's private key and the recipient's public key, and delivering the symmetric key by key agreement, an EncryptionInfo element will be as follows:
[01] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="encryptionInfo23"> [02] <SingleKeyEncryptionInfo> [03] <KeyInfo> [04] <EncryptedKeyValue URI="#encryptionInfo27" IV="d03L...">k0xFFH56...</EncryptedKeyValue> [05] </KeyInfo> [06] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#des-cbc-pkcs5padding" /> [07] </SingleKeyEncryptionInfo> [08] </EncryptionInfo> [09] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="encryptionInfo27"> [10] <SingleKeyEncryptionInfo> [11] <KeyAgreement> [12] <X509Data>...</X509Data> <!-- Originator's certificate --> [13] <X509Data>...</X509Data> <!-- Recipient's certificate --> [14] </KeyAgreement> [15] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#des-cbc-pkcs5padding" /> [16] </SingleKeyEncryptionInfo> [17] </EncryptionInfo> |
[11-14] When using key agreement, the KeyAgreement element should be used instead of the KeyInfo element. The element contains X509Data elements for certificates of originator's and recipient's public keys.
When encrypting contents with recipients' public keys directly, an EncryptionInfo element will be as follows:
[01] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="encryptionInfo23"> [02] <MultipleKeysEncryptionInfo> [03] <SingleKeyEncryptionInfoList> [04] <SingleKeyEncryptionInfo> [05] <KeyInfo> [06] <X509Data>...</X509Data> <!-- Recipient A's certificate --> [07] </KeyInfo> [08] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#rsa" /> [09] </SingleKeyEncryptionInfo> [10] <SingleKeyEncryptionInfo> [11] <KeyInfo> [12] <X509Data>...</X509Data> <!-- Recipient B's certificate --> [13] </KeyInfo> [14] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#rsa" /> [15] </SingleKeyEncryptionInfo> [16] </SingleKeyEncryptionInfoList> [17] <ApplicationMethod Algorithm="http://www.w3.org/2000/10/xmlenc#in-order"/> [18] </MultipleKeysEncryptionInfo> [19] </EncryptionInfo> |
[02-18] When using one or more encryption keys, the MultipleKeysEncryptionInfo element should be used. The element contains the keys, their application method, and optional meta-information relative to application.
[03-16] The SingleKeyEncryptionInfoList element consists of one or more SingleKeyEncryptionInfo elements.
[17] The ApplicationMethod element specifies how encryption keys are applied to encryption, using the Algorithm attribute. It is assumed that "in-order" specified here means that each key is applied in order.
The meta-information includes the encryption time, the originator, recipients, the message length, the data type, the expiration date, decryption policies, and so on. Because required meta-information varies according to contexts, this specification defines only an element for containing any meta-information, that is, Property. Applications may place their own meta-information within this element through the XML-namespace facility [NS].
For example, when including the encryption time as meta-information, an EncryptionInfo element will be as follows:
[01] <EncryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="encryptionInfo23"> [02] <SingleKeyEncryptionInfo> [03] <KeyInfo> [04] <KeyName>1234</KeyName> [05] </KeyInfo> [06] <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#des-cbc-pkcs5padding" /> [07] <EncryptionPropertyList> [08] <Property> [09] <timestamp xmlns="http://www.ietf.org/rfcxxxx.txt"> <!-- Encryption time --> [10] <date>20001027</date> [11] <time>192030</time> [12] </timestamp> [13] </Property> [14] </EncryptionPropertyList> [15] </SingleKeyEncryptionInfo> [16] </EncryptionInfo> |
[08-13] This element contains a timestamp element defined in another namespace.
TBD.
In [PROP1], an IV (if present) is contained in an ContentEncryptionMethod element. The IV should be encoded into an encrypted content or be contained in the syntax for it because the IV will be normally different for every encrypted content. In particular, when multiple contents are encrypted with a single key and the encrypted contents reference the key, the current EncryptionInfo element has no way of containing multiple IVs. The syntax for encrypted contents should be designed after considering this point.
The following have been changed from [PROP1]:
There are some discussions as follows:
| [3DES] | ANSI. Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52, 1998. |
| [C14N] | W3C. Canonical XML Version 1.0, 2000. |
| [CMS] | Cryptographic Message Syntax, RFC 2630, 1999. |
| [DSIG] | W3C. XML-Signature Syntax and Processing, 2000. |
| [ESDH] | Diffie-Hellman Key Agreement Method, RFC 2631, 1999. |
| [MIME] | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, 1996. |
| [NS] | W3C. Namespaces in XML, 1999. |
| [PKCS1] | PKCS #1: RSA Encryption Version 1.5, RFC2313, 1998. |
| [PKCS5] | RSA Laboratories. PKCS #5: Password-Based Encryption Standard, 1993. |
| [PKCS7] | PKCS #7: Cryptographic Message Syntax Version 1.5, RFC2315, 1998. |
| [PROP0] | Ed Simon and Brian LaMacchia. XML Encryption Syntax and Processing, 2000. |
| [PROP1] | Takeshi Imamura and Hiroshi Maruyama, Specification of Element-wise XML Encryption, 2000. |
| [REQ] | Hiroshi Maruyama and Takeshi Imamura, Element-wise XML Encryption, 2000. |
| [XSS4J] | IBM. XML Security Suite, 2000. |