Logo BKA Open Interfaces
for e-Government		 Logo A-SIT

The Austrian Citizen Card

Minimum Implementation of the Security Layer

Document information

Designation

Minimum implementation of the Security Layer for the Austrian Citizen Card

Brief designation

Minimum implementation of the Security Layer

Version

1.2.5

Date

2013-07-22

Document class

Convention

Document status

Recommendation

Short Name

This document describes the following requirements for a minimum implementation of the Security Layer interface by a Citizen Card Environment:

  • Interface commands;

  • Transport protocols;

  • Profile for creating and verifying CMS signatures;

  • Profile for creating and verifying XML signatures;

  • Profile for encrypting and decrypting CMS;

  • Profile for encrypting and decrypting XML;

  • Profile for calculating and verifying hash values;

  • Viewer formats and character sets.

Authors

Arno Hollosi
Gregor Karlinger
Thomas Rössler
Martin Centner
et al.

Work group

Federal Chancellery, Federal Staff Unit for ICT Strategy, Technology and Standards

©

This specification is supplied by A-SIT and the Federal Chancellery. It may be used without modification provided that reference is made to this copyright notice. The specification may be expanded, however any additional material must be clearly identified and the expanded specification must be made freely available.

Table of contents

  1. Introduction
    1. Naming conventions
    2. Keywords
  2. Interface commands of the Security Layer
  3. Security Layer transport protocols
  4. Profile for CMS signatures
    1. Creating a signature
    2. Verifying a signature
  5. Profile for XML signatures
    1. Creating a signature
    2. Verifying a signature
  6. Profile for CMS encryption
    1. Encryption
    2. Decryption
  7. Profile for XML encryption
    1. Encryption
    2. Decryption
  8. Profile for hash values
    1. Hash value calculation
    2. Hash value verification
  9. Viewer formats and character sets
    1. Formats for display in the secure viewer of the Citizen Card Environment
    2. Character sets for the interface protocol
  10. References
  11. History

1 Introduction

This document describes the requirements for a minimum implementation of the Security Layer interface by means of a Citizen Card Environment. In order to conform to the Citizen Card model, a Citizen Card Environment must implement all the functions identified in the following chapters as required or recommended. In well-founded exceptional cases, it is possible to omit functions identified as recommended (compare the meaning of the keyword recommended in [Keywords]).

1.1 Naming conventions

For better readability, this document dispenses with non-gender-specific formulations. However, the formulations expressly relate to both sexes.

The following name space prefixes are used in this specification to identify the name spaces of XML elements:

Prefix
Name space
Explanation
dsig http://www.w3.org/2000/09/xmldsig# Elements from [XMLDSIG]
dsm http://www.w3.org/2001/04/xmldsig-more# Elements from [ECDSA-XML]
xenc http://www.w3.org/2001/04/xmlenc# Elements from [XMLEnc]
sl http://www.buergerkarte.at/namespaces/securitylayer/1.2# Elements of this specification

1.2 Keywords

This document uses the following keywords to categorise requirements: must, must not, required, should, should not, recommended, may and optional. The interpretation of these keywords is set down in [Keywords].

2 Interface commands of the Security Layer

The following table lists all the interface commands specified in the Security Layer application interface. The following table indicates whether each transport protocol has to be contained (required or recommended requirement level) or does not have to be contained (optional requirement level) in a minimum implementation of the Citizen Card Environment.

Signature command Command name Requirement
Create a signature in CMS format sl:CreateCMSSignatureRequest
sl:CreateCMSSigantureResponse		 recommended
Create a signature in XMLDSIG format sl:CreateXMLSignatureRequest
sl:CreateXMLSignatureResponse		 required
Verify a signature in CMS format sl:VerifyCMSSignatureRequest
sl:VerifyCMSSignatureResponse		 recommended
Verify a signature in XMLDSIG format sl:VerifyXMLSignatureRequest
sl:VerifyXMLSignatureResponse 		recommended
Encrypt as a CMS message sl:EncryptCMSRequest
sl:EncryptCMSResponse		 recommended
Encrypt as an XML message sl:EncryptXMLRequest
sl:EncryptXMLResponse		 recommended
Decrypt a CMS message sl:DecryptCMSRequest
sl:DecryptCMSResponse		 recommended
Decrypt an XML message sl:DecryptXMLRequest
sl:DecryptXMLResponse 		recommended
Calculate hash value
 sl:CreateHashRequest
sl:CreateHashResponse 		recommended
Verify hash value
 sl:VerifyHashRequest
sl:VerifyHashResponse 		recommended
Request available info boxes
 sl:InfoboxAvailableRequest
sl:InfoboxAvailableResponse		 required
Create an info box sl:InfoboxCreateRequest
sl:InfoboxCreateResponse		 required
Delete an info box sl:InfoboxDeleteRequest
sl:InfoboxDeleteResponse		 required
Read info box data sl:InfoboxReadRequest
sl:InfoboxReadResponse		 required
Change info box data sl:InfoboxUpdateRequest
sl:InfoboxUpdateResponse		 required
Null operation sl:NullOperationRequest
sl:NullOperationResponse		 required
Request environment properties sl:GetPropertiesRequest
sl:GetPropertiesResponse 		required
Request token status sl:GetStatusRequest
sl:GetStatusResponse		 required
Batch signature and verification sl:BulkRequest
sl:BulkResponse		 recommended
Read PIN state and change PIN on card sl:CardManagementRequest
sl:CardManagementResponse		 recommended
CardCannel commands for the card sl:CardChannelRequest
sl:CardChannelResponse		 recommended

3 Security Layer transport protocols

The Security Layer transport protocols document describes a series of possible transport protocols for the Security Layer application interface. The following table indicates whether each transport protocol has to be contained required or recommended requirement level) or does not have to be contained (optional requirement level) in a minimum implementation of the Citizen Card Environment.

Transport protocol Context
Local CCE(1) Server-based CCE(1)
TCP/IP recommended optional
SSL/TLS optional optional
HTTP required optional
HTTPS required required

(1) For the distinction between a local and a server-based Citizen Card Environment see Introduction to the Austrian Citizen Card, section 1.

4 Profile for CMS signatures

4.1 Creating a signature

This section specifies a profile of [CMS] that must be used by a Citizen Card Environment in the context of the CreateCMSSignature command. If the command CreateCMSSignature gets implemented, the resulting signature MUST cope with the requirements defined in [CAdES] BES (Version 2.2.1) und [CAdES-Baseline] B-Level (Version 2.2.1).

4.1.1 Digest algorithms

If a CMS-signature uses the key from the Keybox SecureSignatureKeypair (c.f. section 2.1) an allowed algorithm according to [SigV] MUST be used to calculate the Message Digest according to [CMS], section 5.4.

Note: Because [SigV] specifies the use of collision resistant hash-functions and because of the progress within crypto analysis SHA-1 should not be used anymore. The use of SHA-256 or RIPEMD160 is recommended here.

4.1.2 Signature algorithms

The algorithm for calculating the signature value according to [CMS], section 5.5, depends on the signature key of the Citizen Card Environment. If a CMS signature uses the key from the key box SecureSignatureKeypair, then an algorithm for the calculation of the signature value according to [SigV] MUST be used.

Note: Because [SigV] specifies the use of collision resistant hash-functions and because of the progress within crypto analysis SHA-1 should not be used anymore. The use of SHA-256 or RIPEMD160 is recommended here. For RSA keys, if technically possible, the algorithm RSA-SHA256, or else RSA-RIPEMD160 and for ECDSA keys, if technically possible, the algorithm ECDSA-SHA256 or else ECDSA-RIPEMD160 is recommended.

4.1.3 Key information

Information about the location of the verification key can be specified in a CMS signature in the form of a collection of X509 certificates in the certificates field (cf. [CMS], section 5.1). The Citizen Card Environment must always include the signatory certificate in this collection. It is also recommended that the whole chain of certificates required to verify the signature (signatory certificate up to a trust-worthy root instance) should also be included in this collection.

4.1.4 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references in the context of the CreateCMSSignature command.

Protocol
Context
sl:DataObject/sl:Content/@Reference
http
required
https
required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

4.2 Verifying a signature

This section specifies a profile of [CMS] that must be encompassed by a Citizen Card Environment in the context of the VerifyCMSSignature command.

4.2.1 Digest algorithms

The Citizen Card Environment MUST support all algorithms used for calculating the Message Digest in the context of signature verification according to [CMS], section 5.6.

Note: In terms of interoperability between different Citizen Card Environments it is recommended to support at least the algorithms specified in 4.1.1 (SHA-256, RIPEMD-160) and SHA-1.

4.2.2 Signature algorithms

The Citizen Card Environment MUST support all signature algorithms that may be used for calculation also for the verification according to [CMS], section 5.6.

Note: In terms of interoperability between different Citizen Card Environments it is recommended to support at least the algorithms specified in 4.1.2 (RSA-SHA256, ECDSA-SHA256, RSA-RIPEMD160, ECDSA-RIPEMD160) and RSA respectiveyly DSA according to [CMS-Alg] 3.2 (3.1) and ECDSA according to [ECDSA-CMS] 2.2.1.

4.2.3 Key information

Information about the location of the verification key can be specified in a CMS signature in the form of a collection of X509 certificates in the certificates field (cf. [CMS], section 5.1). The Citizen Card Environment may use this information to find the verification key and to form the certificate chain towards a trust-worthy root.

Furthermore, CMS signature revocation information can be specified in the form of a collection of X509 revocation lists in the crls field (cf. [CMS], section 5.1). The Citizen Card Environment may use this information to determine the status of a certificate when validating a certificate chain.

4.2.4 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references in the context of the VerifyCMSSignature command.

Protocol
Context
sl:DataObject/sl:Content/@Reference
http
required
https
required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

5 Profile for XML signatures

5.1 Creating a signature

This section specifies a profile of [XMLDSIG] that must be used by a Citizen Card Environment in the context of the CreateXMLSignature command.

The resulting signature MUST meet the requirements defined in [XAdES] (Version 1.4.2).

5.1.1 Digest algorithms

If an XML-signature uses the key from the Keybox SecureSignatureKeypair (c.f. section 2.1) an allowed algorithm according to [SigV] MUST be used to calculate the Message Digest.

Note: Because [SigV] specifies the use of collision resistant hash-functions and because of the progress within crypto analysis SHA-1 should not be used anymore. The use of SHA-256 or RIPEMD160 is recommended here.

5.1.2 Signature algorithms

The algorithm for calculating the signature value according to[XMLDSIG], section 3.1.2, depends on the signature key of the Citizen Card Environment. If an XML signature uses the key from the key box SecureSignatureKeypair, then an algorithm for the calculation of the signature value according to [SigV] MUST be used.

Note: Because [SigV] specifies the use of collision resistant hash-functions and because of the progress within crypto analysis SHA-1 should not be used anymore. The use of SHA-256 or RIPEMD160 is recommended here. For RSA keys, if technically possible, the algorithm RSA-SHA256 according to [XMLDSIG-URI] (section 2.3.1), or else RSA-RIPEMD160 accordig to [XMLDSIG-URI] (section 2.3.5); for ECDSA keys, if technically possible, the algorithm ECDSA-SHA256 according to [XMLDSIG-URI] (section 2.3.6) or else ECDSA-RIPEMD160(3) is recommended.

5.1.3 Canonicalisation algorithms

The following table specifies the requirement levels for the Citizen Card Environment in relation to the support for canonicalisation algorithms in the context of the CreateXMLSignature command.

Designation URI Normative reference Requirement
C14N http://www.w3.org/TR/2001/REC-xml-c14n-20010315 [XMLDSIG], 6.5.1 required
C14N with comments http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments [XMLDSIG], 6.5.1 required
EC14N http://www.w3.org/2001/10/xml-exc-c14n# [EC14N], 4 required
EC14N with comments http://www.w3.org/2001/10/xml-exc-c14n#WithComments [EC14N], 4 required

5.1.4 Transformation algorithms

The following table specifies the requirement levels for the Citizen Card Environment in relation to the support for transformation algorithms in the context of the CreateXMLSignature command.

Designation URI Normative reference Requirement
C14N http://www.w3.org/TR/2001/REC-xml-c14n-20010315 [XMLDSIG], 6.5.1 required
C14N with comments http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments [XMLDSIG], 6.5.1 required
EC14N http://www.w3.org/2001/10/xml-exc-c14n# [EC14N], 4 required
EC14N with comments http://www.w3.org/2001/10/xml-exc-c14n#WithComments [EC14N], 4 required
Base64 Decoder http://www.w3.org/2000/09/xmldsig#base64
[XMLDSIG], 6.6.2 required
XPath Filter 1 http://www.w3.org/TR/1999/REC-xpath-19991116 [XMLDSIG], 6.6.3 required
XPath Filer 2 http://www.w3.org/2002/06/xmldsig-filter2 [XPF2] required
Enveloped Signature http://www.w3.org/2000/09/xmldsig#enveloped-signature [XMLDSIG], 6.6.4 required
XSLT http://www.w3.org/TR/1999/REC-xslt-19991116
[XMLDSIG], 6.6.5 required
Binary Mode Decryption http://www.w3.org/2002/07/decrypt#Binary [XMLDecTF], 4 optional
XML Mode Decryption(1) http://www.w3.org/2002/07/decrypt#XML [XMLDecTF], 3 optional

(1) When an XML Mode Decryption transformation is used when creating an XML signature, the Citizen Card Environment must use the mechanism from [XMLDecTF], section 3.2.

5.1.5 Key information

Information about the location of the verification key in the dsig:KeyInfo XML element can be specified in an XML signature (cf. [XMLDSIG], section 4.4). The Citizen Card Environment must always include the signatory certificate in this XML element. Furthermore, it is recommended that the whole chain of certificates required to verify the signature (signatory certificate up to a trust-worthy instance) should also be included in this XML element.

5.1.6 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references in the context of the CreateXMLSignature command.

Protocol http https formdata ID reference XPointer reference(2)
C
o
n
t
e
x
t		 sl:DataObjectInfo/
sl:DataObject/
@Reference
required
 required required required recommended
sl:DataObjectInfo/
sl:DataObject/
sl:LocRefContent
required
 required required n.a. n.a.
Imported style sheets(1) required required required n.a. n.a.
sl:DataObjectInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent		 required required required n.a. n.a.
sl:SignatureInfo/
sl:SignatureEnvironment/
@Reference		 required required required n.a. n.a.
sl:SignatureInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent		 required required required n.a. n.a.

(1) Style sheet imports specified in an XSLT transformation of a data object.

(2) XPointer according to [XPointerFW] containing xmlns (cf. [XPointerNS]) and element (cf. [XPointerEL]) XPointer Parts.

5.2 Verifying a signature

This section specifies a profile of [XMLDSIG] that must be encompassed by a Citizen Card Environment in the context of the VerifyXMLSignature command.

5.2.1 Digest algorithms

The Citizen Card Environment MUST support all algorithms for calculating the Message Digest during signature verification according to [XMLDSIG], section 3.2.

Note: In terms of interoperability between different Citizen Card Environments it is recommended to support at least the algorithms specified in section 5.1.1 (SHA-256, RIPEMD-160) and SHA-1 [XMLDSIG], section 3.2.

5.2.2 Signature algorithms

The Citizen Card Environment MUST support all signature algorithms that may be used for calculation also for the verification according to [XMLDSIG], section 3.2.

Note: In terms of interoperability between different Citizen Card Environments it is recommended to support at least the algorithms specified in 5.1.2 (RSA-SHA256, ECDSA-SHA256, RSA-RIPEMD160, ECDSA-RIPEMD160) and RSA respectiveyly DSA according to [XMLDSIG] 6.4.2 (6.4.1) and ECDSA according to [XMLDSIG-URI] 2.3.6.

5.2.3 Canonicalisation algorithms

For the table of requirement levels for the Citizen Card Environment in relation to the support of canonicalisation algorithms as part of signature verification according to [XMLDSIG], section 3.2, see section 5.1.3.

5.2.4 Transformation algorithms

For the table of requirement levels for the Citizen Card Environment in relation to the support of transformation algorithms as part of signature verification according to [XMLDSIG], section 3.2, see section 5.1.4.

The specifications in Security Layer application interface, section 5.2 and in section 7.2 of this document apply to both Binary Mode Decryption and XML Mode Decryption transformations.

5.2.5 Key information

Information about the location of the verification key in the dsig:KeyInfo XML element can be specified in an XML signature (cf. [XMLDSIG], section 4.4). The following table specifies the requirement levels for the Citizen Card Environment in relation to the support for XML elements that can arise there. All XML elements not explicitly named in the table may be evaluated by the Citizen Card Environment.

Child element Requirement Note
dsig:RSAKeyValue optional -
dsig:DSAKeyValue optional -
dsm:ECDSAKeyValue optional -
dsig:X509IssuerSerial optional This XML element clearly identifies a particular certificate. This means that the Citizen Card Environment can allocate a certificate from its own cache if necessary.
dsig:X509Certificate required -
dsig:X509CRL optional A revocation list encoded with this XML element must be understood by the Citizen Card Environment but not necessarily used by it (e.g. because a more up-to-date version can be called up from a distribution point).

5.2.6 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references in the context of the VerifyXMLSignature command.

Protocol http https ldap formdata ID reference XPointer reference(2)
C
o
n
t
e
x
t		 sl:SignatureInfo/
sl:SignatureEnvironment/
@Reference
required
 required optional required n.a. n.a.
sl:Supplement/
sl:Content/
sl:LocRefContent
required
 required optional required n.a. n.a.
Imported style sheets(1) required required optional required n.a. n.a.
dsig:Signature/
dsig:SignedInfo/
dsig:Reference/
@URI		 required required optional required required recommended
dsig:Manifest/
dsig:Reference/
@URI 		required required optional required required recommended
dsig:Signature/
dsig:KeyInfo/
dsig:RetrievalMethod/
@URI		 required required required required required recommended

(1) Style sheet imports specified in an XSLT transformation of an XML signature.

(2) XPointer according to [XPointerFW] containing xmlns (cf. [XPointerNS]) and element (cf. [XPointerEL]) XPointer Parts.

6 Profile for CMS encryption

6.1 Encryption

This section specifies a profile of [CMS] that must be used by a Citizen Card Environment in the context of the EncryptCMS command.

6.1.1 Algorithms

When creating encrypted CMS messages, a Citizen Card Environment must use one of the algorithms mentioned in section 6.2.1. for key transport and one of the algorithms mentioned in section 6.2.1.2 for data encryption.

In view of the widespread use, it is currently recommended that the PKCS #1 v1.5 algorithm should be used for key transport and the Triple DES CBC algorithm for data encryption.

6.1.2 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references.

Protocol
Context
sl:ToBeEncrypted/@Reference
http
required
https
required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

6.2 Decryption

This section specifies a profile of [CMS] that must be encompassed by a Citizen Card Environment in the context of the DecryptCMS command.

6.2.1 Algorithms

This section specifies the requirement levels for the Citizen Card Environment in relation to the support of algorithms in the CMS message to be decrypted. In principle a Citizen Card Environment must only support key transport relating to the encryption of the data encryption key. For this reason, this section contains no information about other key management techniques.

6.2.1.1 Key transport

The following table specifies the requirement levels for the Citizen Card Environment in relation to the support of algorithms for key transport (ktri field of the CMS message).

Designation
OID
Normative reference
Requirement
PKCS #1 v1.5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } [CMS-Alg], 4.2.1 required
RSAES-OAEP { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } [CMS-RSAES-OAEP] recommended

6.2.1.2 Data encryption

The following table specifies the requirement levels for the Citizen Card Environment in relation to the support of algorithms for data encryption (contentEncryptionAlgorithm field of the CMS message).

Designation
OID
Normative reference
Requirement
Triple-DES CBC { des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } [CMS-Alg], 5.1 required
AES CBC 128 bit { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 1 2 } [CMS-AES] recommended
AES CBC 256 bit { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 1 42 } [CMS-AES] recommended

6.2.2 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references.

Protocol
Context
sl:EncryptedContent/sl:Content/@Reference
http
required
https
required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

7 Profile for XML encryption

7.1 Encryption

This section specifies a profile of [XMLEnc] that must be used by a Citizen Card Environment in the context of the EncryptXML command.

7.1.1 Algorithms

When creating encrypted XML messages, a Citizen Card Environment must use for data encryption purposes one of the algorithms mentioned in section 7.2.1.1 for block encryption, and for key transport one of the algorithms mentioned in section 7.2.1.2.; for key agreement one of the algorithms defined in section 7.2.1.3 MUST be used.

In view of the widespread use, it is currently recommended that the RSA Version 1.5 algorithm should be used for key transport and the AES-CBC (128bit) algorithm for data encryption.

7.1.2 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references.

Protocol
Context
sl:ToBeEncrypted/
sl:New/
sl:LocRefContent		 sl:EncryptionInfo/
sl:EncryptionEnvironment/
@Reference		 sl:EncryptionInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent
http required required required
https required required required
formdata(1) required required required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

7.2 Decryption

This section specifies a profile of [XMLEnc] that must be encompassed by a Citizen Card Environment in the context of the DecryptXML command.

7.2.1 Algorithms

7.2.1.1 Algorithms for xenc:EncryptedData

The following table specifies the requirement levels for the Citizen Card Environment in relation to algorithms in xenc:EncryptedData/xenc:EncryptionMethod/@Algorithm.

Designation
URI
Normative reference
Requirement
Block encryption
Triple DES http://www.w3.org/2001/04/xmlenc#tripledes-cbc [XMLEnc], 5.2.1 required
AES CBC 128 bit http://www.w3.org/2001/04/xmlenc#aes128-cbc [XMLEnc], 5.2.2 required
AES CBC 256 bit http://www.w3.org/2001/04/xmlenc#aes256-cbc [XMLEnc], 5.2.2 required
Key transport (1)
RSA Version 1.5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 [XMLEnc], 5.4.1 required
RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p [XMLEnc], 5.4.2 required

(1)See note in [XMLEnc], section 5.4.

7.2.1.2 Algorithms for xenc:EncryptedKey

The following table specifies the requirement levels for the Citizen Card Environment in relation to algorithms in xenc:EncryptedKey/xenc:EncryptionMethod/@Algorithm.

Designation
URI
Normative reference
Requirement
Key transport
RSA Version 1.5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 [XMLEnc], 5.4.1 required
RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p [XMLEnc], 5.4.2 required
Key encryption (Symmetric Key Wrap)
CMS Triple DES Key Wrap http://www.w3.org/2001/04/xmlenc#kw-tripledes [XMLEnc], 5.6.2 recommended
AES KeyWrap 128 Bit http://www.w3.org/2001/04/xmlenc#kw-aes128 [XMLEnc], 5.6.3 recommended
AES KeyWrap 256 Bit http://www.w3.org/2001/04/xmlenc#kw-aes256 [XMLEnc], 5.6.3 recommended
Block encryption
Triple DES http://www.w3.org/2001/04/xmlenc#tripledes-cbc [XMLEnc], 5.2.1 required
AES CBC 128 Bit http://www.w3.org/2001/04/xmlenc#aes128-cbc [XMLEnc], 5.2.2 required
AES CBC 256 Bit http://www.w3.org/2001/04/xmlenc#aes256-cbc [XMLEnc], 5.2.2 required

7.2.1.3 Algorithms for xenc:KeyAgreement

The following table specifies the requirement levels for the Citizen Card Environment in relation to algorithms in xenc:EncryptedKey/xenc:KeyInfo/xenc:KeyAgreement/@Algorithm.

Designation
URI
Normative reference
Requirement
Key agreement
Diffie-Hellman Key Agreement http://www.w3.org/2001/04/xmlenc#dh [XMLEnc], 5.5.2 recommended

7.2.2 Key information

7.2.2.1 Key information in xenc:Encryp

The following table specifies the requirement levels for the Citizen Card Environment in relation to key information in xenc:EncryptedData/dsig:KeyInfo.

Element name
Note
Normative reference
Requirement
dsig:KeyName Must contain the KeyboxIdentifier for a key pair contained in the Citizen Card Environment that is suitable for encryption. [XMLDSIG], 4.4.1 required
dsig:KeyValue Must contain the public key for a key pair contained in the Citizen Card Environment that is suitable for encryption. [XMLDSIG], 4.4.2 required
dsig:X509Data Must contain precisely one dsig:X509Certificate element with the certificate for the public key of a key pair contained in the Citizen Card Environment. [XMLDSIG], 4.4.4 required
xenc:EncryptedKey   [XMLEnc], 3.5.1 required
dsig:RetrievalInfo Must refer to an xenc:EncryptedKey in the same XML document. Transformations do not have to be supported by the Citizen Card Environment. [XMLEnc], 3.5.2 required

7.2.2.2 Key information in xenc:EncryptedKey

The following table specifies the requirement levels for the Citizen Card Environment in relation to key information in xenc:EncryptedKey/dsig:KeyInfo.

Element name Note Normative reference Requirement
dsig:KeyName Must contain the KeyboxIdentifier for a key pair contained in the Citizen Card Environment that is suitable for encryption. [XMLDSIG], 4.4.1 required
dsig:KeyValue Must contain the public key for a key pair contained in the Citizen Card Environment that is suitable for encryption. [XMLDSIG], 4.4.2 required
dsig:X509Data Must contain precisely one dsig:X509Certificate element with the certificate for the public key of a key pair contained in the Citizen Card Environment. [XMLDSIG], 4.4.4 required
xenc:AgreementMethod
  • The attribute xenc:AgreementMethod/@Algorithm MUST contain an algorithm's URI defined within section 7.2.1.3. 
  • The element xenc:AgreementMethod/dsig:DigestMethod MUST reference one of the algorithms defined within section 5.1.1.
  • The element xenc:AgreementMethod/xenc:RecipientKeyInfo MUST contain EXACTLY one of the elements above, dsig:KeyName, dsig:KeyValue or dsig:X509Data.
  • The element xech:AgreementMethod/xenc:OriginatorKeyInfo MUST contain EXACTLY on element dsig:KeyValue.
 [XMLEnc], 5.5 optional

7.2.3 Resolution of references

The following table specifies the level of requirements for the Citizen Card Environment in relation to the protocols when resolving references in different contexts.

Protocol
Context
dsig:RetrievalMethod xenc:EncryptedData/
xenc:Value		 xenc:EncryptedKey/
xenc:Value		 sl:Supplement/
sl:Content/
sl:LocRefContent
http
optional
required
required
required
https
optional
required
required
required
formdata(1)
optional
required
required
required
relative URI(2)
optional(4)
required(4)
required(4)
must not
ID reference(3)
required
optional
optional
must not

(1) Compare Security Layer transport protocols, section 3.2.1.2.

(2) A relative URI is a URI that does not contain a protocol element (cf. [RFC2396], 3.1).

(3) An ID reference is a Same Document Reference according to [RFC2396], 4.2, which contains the value of an attribute of type IDREF according to [XML].

(4) A relative URI may only be resolved using a Supplement specified for this URI; a direct resolution (e.g. by making the reference absolute in relation to the local file system) must not take place.

8 Profile for hash values

8.1 Hash value calculation

This section specifies a minimum profile for the CreateHash command that must be encompassed by a Citizen Card Environment.

8.1.1 Digest algorithms

The Citizen Card Environment must support all algorithms for calculating the Message Digest that are also supported for the XML signature verification.

8.1.2 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references.

Protocol
Context
sl:HashInfo/
sl:HashData/
sl:Content/
@Reference
http required
https required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

8.2 Hash value verification

This section specifies a minimum profile for the VerifyHash command that must be encompassed by a Citizen Card Environment.

8.2.1 Digest algorithms

The Citizen Card Environment must support all algorithms (SHA-1) for calculating the Message Digest, as listed in [XMLDSIG], section 6.2.

8.2.2 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references.

Protocol
Context
sl:HashInfo/
sl:HashData/
sl:Content/
@Reference
http required
https required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

9 Viewer formats and character sets

9.1 Formats for display in the secure viewer of the Citizen Card Environment

For the purpose of processing the interface commands for creating and verifying signatures (CreateCMSSignature, CreateXMLSignature and VerifyCMSSignature, VerifyXMLSignature respectively), the Citizen Card Environment requires a viewer component to show citizens the data that needs to be signed or that has been signed. This section defines which viewer formats must be supported by the viewer component of the Citizen Card Environment.

9.1.1 Text

The Citizen Card Environment must be able to display text as the simplest format. The following table lists the Unicode characters [Unicode] that it must be able to display.

Note: These are the characters required to be able to display the character sets [ISO-8859-1], [ISO-8859-2], [ISO-8859-3], [ISO-8859-9], [ISO-8859-10] and [ISO-8859-15] except for most of the control characters contained there.

Code Chart Character number(s) Code Chart Character number(s)
C0 Controls and Basic Latin 0x0009-0x000A Latin Extended-A 0x014A-0x014D
C0 Controls and Basic Latin 0x000C-0x000D Latin Extended-A 0x0150-0x0155
C0 Controls and Basic Latin 0x0020-0x007E Latin Extended-A 0x0158-0x0173
C1 Controls and Latin-1 Supplement 0x00A1-0x00FF Latin Extended-A 0x0178-0x017E
Latin Extended-A 0x0100-0x0114 Spacing Modifier Letters 0x02C7
Latin Extended-A 0x0116-0x012B Spacing Modifier Letters 0x02D8-0x02D9
Latin Extended-A 0x012E-0x0131 Spacing Modifier Letters 0x02DB
Latin Extended-A 0x0134-0x013E Spacing Modifier Letters 0x02DD
Latin Extended-A 0x0141-0x0148 General Punctuation 0x2015

The Citizen Card Environment must attempt to interpret the following data as text:

The Citizen Card Environment must use a font with a constant width for each character (monospaced) to display text. The Citizen Card Environment must use a tabulator width of eight characters for the 0x0009 character (tabulator).

9.1.2 Standardised viewer format of the Security Layer

The Citizen Card Environment must be able to display the standardised viewer format as a format for displaying more complex documents. The specifications contained in section 9.1.1 apply in relation to the characters that the Citizen Card Environment must be able to display.

The Citizen Card Environment must attempt to interpret the following data in line with this format:

9.2 Character sets for the interface protocol

When request commands are received via the interface of the Security Layer, the Citizen Card Environment MUST support the three character sets ISO-8859-1 [ISO-8859-1], ISO-8859-15 [ISO-8859-15] and UTF-8 [Unicode]. The application MUST specify the character set used in the XML declaration of the XML document containing the request command.

10 References

CAdES
European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES) v2.2.1 , Technical Specification, April 2013
CAdES-Baseline
European Telecommunications Standards Institute: ETSI TS 103173: Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile v2.2.1 , Technical Specification, April 2013
CMS
Hously, R.: RFC 3369: Cryptographic Message Syntax (CMS). IETF Request For Comment, August 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc3369.txt.
CMS-AES
Schaad, J.: RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). IETF Request For Comment, July 2003. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc3565.txt.
CMS-Alg
Hously, R.: RFC 3370: Cryptographic Message Syntax (CMS) Algorithms. IETF Request For Comment, August 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc3370.txt.
CMS-RSAES-OAEP
Hously, R.: RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS). IETF Request For Comment, July 2003. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc3560.txt.
EC14N
Boyer, John, Eastlake, Donald and Reagle, Joseph: Exclusive XML Canonicalization. W3C Recommendation, July 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/.
ECDSA-CMS
Blake-Wilson, S., Brown, D., Lampert, D.: RFC 3278: Use of Elliptic Curve Cryptography (ECC) Algorithms
in Cryptographic Message Syntax (CMS). IETF Request For Comment, April 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc3278.txt.
ECDSA-XML
Blake-Wilson, S., Karlinger, G. and Wang, Y.: ECDSA with XML-Signature Syntax. Internet Draft, January 2004. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/internet-drafts/draft-blake-wilson-xmldsig-ecdsa-08.txt.
ISO-8859-1
ISO/IEC 8859-1:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1.
ISO-8859-2
ISO/IEC 8859-2:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 2: Latin alphabet No. 2.
ISO-8859-3
ISO/IEC 8859-3:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 3: Latin alphabet No. 3.
ISO-8859-9
ISO/IEC 8859-9:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 9: Latin alphabet No. 5.
ISO-8859-10
ISO/IEC 8859-10:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 10: Latin alphabet No. 6.
ISO-8859-15
ISO/IEC 8859-15:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 15: Latin alphabet No. 9.
Keywords
Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment, March 1997. Downloaded from the World Wide Web on 31 August 2002 under http://www.ietf.org/rfc/rfc2119.txt.
MIME
Freed, N. and Borenstein, N.: RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. IETF Request For Comment, November 1996. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc2046.txt.
RFC2396
Berners-Lee, T., Fielding, R., Irvine, U.C. and Masinter, L.: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. IETF Request For Comments, August 1998. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc2396.txt.
SigV
BGBl. II Nr. 3/2008, aktuelle Fassung.
XAdES
European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.4.2 , Technical Specification, Dezember 2010
XML
Bray, Tim, Paoli, Jean, Sperberg-McQueen, C.M. and Maler, Eve: Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation, Oktober 2000. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2000/REC-xml-20001006.
XMLDecTF
Hughes, Merlin, Imamura, Takeshi and Maruyama, Hiroshi: Decryption Transform for XML Signature. W3C Recommendation, December 2002. Downloaded form the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210.
XMLEnc
Eastlake, Donald and Reagle, Joseph: XML Encryption Syntax and Processing. W3C Recommendation, December 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.
XMLDSIG
Eastlake, Donald, Reagle, Joseph and Solo, David: XML-Signature Syntax and Processing. W3C Recommendation, February 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.
XMLDSIG-URI 
Eastlake, Donald: RFC 4051: Additional XML Security Uniform Resource Identifiers (URIs) , IETF Request For Comments, April 2005
XPointer-EL
Grosso, Paul, Maler, Eve, Marsh, Jonathan and Walsh, Norman: XPointer Framework. W3C Recommendation, March 2003. Downloaded from the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2003/REC-xptr-element-20030325/.
XPointer-FW
Grosso, Paul, Maler, Eve, Marsh, Jonathan and Walsh, Norman: XPointer Framework. W3C Recommendation, March 2003. Downloaded from the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2003/REC-xptr-framework-20030325/.
XPointer-NS
DeRose, Steven J., Daniel, Ron Jr, Marsh, Jonathan and Walsh, Norman: XPointer Framework. W3C Recommendation, March 2003. Downloaded from the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/.
Unicode
The Unicode Consortium. The Unicode Standard, Version 4.0.0, defined by: The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1). Downloaded from the World Wide Web on 14 May 2004 under http://www.unicode.org/versions/Unicode4.0.0/.
XPF2
Boyer, John, Hughes, Merlin and Reagle, Joseph: XML-Signature XPath Filter 2.0. W3C Candidate Recommendation, July 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.w3.org/TR/2002/CR-xmldsig-filter2-20020718/.

11 History

Date
Version
 Changes
2013-07-22 1.2.5
  • Added CardManagement and CardChannel commands
2013-05-15 1.2.4
  • Minimal requirements regarding section 2 have changed:
    • Verifying XMLDSIG signatures: not required anymore
    • Hash value calculation: not required anymord
  • Section 5.1.3 and section 5.1.4 adapted to XAdES baseline profile. Removed items:
    • C14N with comments
    • EC14N with comments
    • Binary Mode Decryption
    • XML Mode Decryption
2013-04-22 1.2.3
  • Added batch signatures
  • Removed the ContentHints element from CMS signatures
  • It is not recommended anymore to include the certificate chain when using XMLDSIG signatures. The Recommendations concerning the elements to include from dsig:KeyInfo in section 5.2.5 have changed.
2013-04-15 1.2.2
  • Minimal standard for CMS signatures set to CAdES 2.2.1
  • Minimal standard for XMLDSIG signatures set to XAdES 1.4.2
2008-02-20 1.2.1
  • Added permitted digest algorithms in section 4, section 5 and section 8
  • Extended the XML encryption profile in section 7 by key agreement
2004-02-29
1.2.0
  • Erratum 3 eliminated according to Errata document.
  • Interface command CreateSymmetricSecret removed from list of interface commands.
  • Interface commands EncryptCMS, EncryptXML, DecryptCMS, DecryptXML, CreateHash, VerifyHash, InfoboxCreate, InfoboxDelete and NullOperation added to the list of interface commands.
  • Sections 4 relating to the profile for CMS signatures added.
  • Former section 3 in relation to XML signatures reorganised as section 5 (separate sections for creation and verification).
  • Sections 6 and 7 relating to profiles for CMS and XML encryption added.
  • Section 8 relating to the profile for calculating and checking the hash value added.
  • Section 9 relating to viewer formats and character sets added.
  • Former section 8 divided into subsections of sections 4 to 7.
2002-08-31
1.1.0
  • Interface commands, signature creation and signature verification according to CMS changed from required to recommended.
  • Interface command for creating a session certificate removed.
  • Profile for XML signatures (verification of an XML signature, creation of an XML signature, negotiation of a symmetrical secret) added.
  • Requirements for the resolution of URIs in request commands and XML signatures to be verified added.
  • Section 1.1 Naming conventions added.
href="#ref-xmldsig">XMLDSIG], 6.5.1 required EC14N http://www.w3.org/2001/10/xml-exc-c14n# [EC14N], 4 required EC14N with comments http://www.w3.org/2001/10/xml-exc-c14n#WithComments [EC14N], 4 required Base64 Decoder http://www.w3.org/2000/09/xmldsig#base64
[XMLDSIG], 6.6.2 required XPath Filter 1 http://www.w3.org/TR/1999/REC-xpath-19991116 [XMLDSIG], 6.6.3 required XPath Filer 2 http://www.w3.org/2002/06/xmldsig-filter2 [XPF2] required Enveloped Signature http://www.w3.org/2000/09/xmldsig#enveloped-signature [XMLDSIG], 6.6.4 required XSLT http://www.w3.org/TR/1999/REC-xslt-19991116
[XMLDSIG], 6.6.5 required Binary Mode Decryption http://www.w3.org/2002/07/decrypt#Binary [XMLDecTF], 4 optional XML Mode Decryption(1) http://www.w3.org/2002/07/decrypt#XML [XMLDecTF], 3 optional

(1) When an XML Mode Decryption transformation is used when creating an XML signature, the Citizen Card Environment must use the mechanism from [XMLDecTF], section 3.2.

(3)Die Verwendung des Algorithmus ECDSA-RIPEMD160 mit XMLDSIG wurde bisher noch nicht normativ definiert. http://tools.ietf.org/id/draft-eastlake-additional-xmlsec-uris-00.txt definiert die Verwendung des Algorithmus ECDSA-RIPEMD160 und den URI http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160.

5.1.5 Key information

Information about the location of the verification key in the dsig:KeyInfo XML element can be specified in an XML signature (cf. [XMLDSIG], section 4.4). The Citizen Card Environment must always include the signatory certificate in this XML element. Furthermore, it is recommended that the whole chain of certificates required to verify the signature (signatory certificate up to a trust-worthy instance) should also be included in this XML element.

5.1.6 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references in the context of the CreateXMLSignature command.

Protocol http https formdata ID reference XPointer reference(2)
C
o
n
t
e
x
t		 sl:DataObjectInfo/
sl:DataObject/
@Reference
required
 required required required recommended
sl:DataObjectInfo/
sl:DataObject/
sl:LocRefContent
required
 required required n.a. n.a.
Imported style sheets(1) required required required n.a. n.a.
sl:DataObjectInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent		 required required required n.a. n.a.
sl:SignatureInfo/
sl:SignatureEnvironment/
@Reference		 required required required n.a. n.a.
sl:SignatureInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent		 required required required n.a. n.a.

(1) Style sheet imports specified in an XSLT transformation of a data object.

(2) XPointer according to [XPointerFW] containing xmlns (cf. [XPointerNS]) and element (cf. [XPointerEL]) XPointer Parts.

5.2 Verifying a signature

This section specifies a profile of [XMLDSIG] that must be encompassed by a Citizen Card Environment in the context of the VerifyXMLSignature command.

5.2.1 Digest algorithms

The Citizen Card Environment MUST support all algorithms (SHA-1) for calculating the Message Digest during signature verification according to [XMLDSIG], section 3.2, as listed in [XMLDSIG], section 6.2.

5.2.2 Signature algorithms

The following table specifies the requirement levels for the Citizen Card Environment in relation to the support of signature algorithms in the context of signature verification according to [XMLDSIG], section 3.2.

Designation URI Normative reference Requirement
RSA-SHA1 http://www.w3.org/2000/09/xmldsig#dsa-sha1 [XMLDSIG], 6.4.2 required
DSA-SHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 [CMS-Alg], 6.4.1 required
ECDSA-SHA1 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1 [ECDSA-XML], 3 required

5.2.3 Canonicalisation algorithms

For the table of requirement levels for the Citizen Card Environment in relation to the support of canonicalisation algorithms as part of signature verification according to [XMLDSIG], section 3.2, see section 5.1.3.

5.2.4 Transformation algorithms

For the table of requirement levels for the Citizen Card Environment in relation to the support of transformation algorithms as part of signature verification according to [XMLDSIG], section 3.2, see section 5.1.4.

The specifications in Security Layer application interface, section 5.2 and in section 7.2 of this document apply to both Binary Mode Decryption and XML Mode Decryption transformations.

5.2.5 Key information

Information about the location of the verification key in the dsig:KeyInfo XML element can be specified in an XML signature (cf. [XMLDSIG], section 4.4). The following table specifies the requirement levels for the Citizen Card Environment in relation to the support for XML elements that can arise there. All XML elements not explicitly named in the table may be evaluated by the Citizen Card Environment.

Child element Requirement Note
dsig:RSAKeyValue recommended -
dsig:DSAKeyValue recommended -
dsm:ECDSAKeyValue recommended -
dsig:X509IssuerSerial recommended This XML element clearly identifies a particular certificate. This means that the Citizen Card Environment can allocate a certificate from its own cache if necessary.
dsig:X509Certificate required -
dsig:X509CRL required A revocation list encoded with this XML element must be understood by the Citizen Card Environment but not necessarily used by it (e.g. because a more up-to-date version can be called up from a distribution point).
dsig:RetrievalMethod with reference to dsig:X509Data required The requirement levels of this table apply for the XML child elements of the dsig:X509Data referenced.
de>https
required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

6.2 Decryption

This section specifies a profile of [CMS] that must be encompassed by a Citizen Card Environment in the context of the DecryptCMS command.

6.2.1 Algorithms

This section specifies the requirement levels for the Citizen Card Environment in relation to the support of algorithms in the CMS message to be decrypted. In principle a Citizen Card Environment must only support key transport relating to the encryption of the data encryption key. For this reason, this section contains no information about other key management techniques.

6.2.1.1 Key transport

The following table specifies the requirement levels for the Citizen Card Environment in relation to the support of algorithms for key transport (ktri field of the CMS message).

Designation
OID
Normative reference
Requirement
PKCS #1 v1.5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } [CMS-Alg], 4.2.1 required
RSAES-OAEP { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } [CMS-RSAES-OAEP] recommended

6.2.1.2 Data encryption

The following table specifies the requirement levels for the Citizen Card Environment in relation to the support of algorithms for data encryption (contentEncryptionAlgorithm field of the CMS message).

Designation
OID
Normative reference
Requirement
Triple-DES CBC { des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } [CMS-Alg], 5.1 required
AES CBC 128 bit { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 1 2 } [CMS-AES] recommended
AES CBC 256 bit { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 1 42 } [CMS-AES] recommended

6.2.2 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references.

Protocol
Context
sl:EncryptedContent/sl:Content/@Reference
http
required
https
required
formdata(1) required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

7 Profile for XML encryption

7.1 Encryption

This section specifies a profile of [XMLEnc] that must be used by a Citizen Card Environment in the context of the EncryptXML command.

7.1.1 Algorithms

When creating encrypted XML messages, a Citizen Card Environment must use for data encryption purposes one of the algorithms mentioned in section 7.2.1.1 for block encryption, and for key transport one of the algorithms mentioned in section 7.2.1.2.; for key agreement one of the algorithms defined in section 7.2.1.3 MUST be used.

In view of the widespread use, it is currently recommended that the RSA Version 1.5 algorithm should be used for key transport and the AES-CBC (128bit) algorithm for data encryption.

7.1.2 Resolution of references

The following table specifies the requirement levels for the Citizen Card Environment in relation to the protocols when resolving references.

Protocol
Context
sl:ToBeEncrypted/
sl:New/
sl:LocRefContent		 sl:EncryptionInfo/
sl:EncryptionEnvironment/
@Reference		 sl:EncryptionInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent
http required required required
https required required required
formdata(1) required required required

(1) Compare Security Layer transport protocols, section 3.2.1.2.

7.2 Decryption

This section specifies a profile of [XMLEnc] that must be encompassed by a Citizen Card Environment in the context of the DecryptXML command.

7.2.1 Algorithms

7.2.1.1 Algorithms for xenc:EncryptedData

The following table specifies the requirement levels for the Citizen Card Environment in relation to algorithms in xenc:EncryptedData/xenc:EncryptionMethod/@Algorithm.

Designation
URI
Normative reference
Requirement
Block encryption
Triple DES http://www.w3.org/2001/04/xmlenc#tripledes-cbc [XMLEnc], 5.2.1 required
AES CBC 128 bit http://www.w3.org/2001/04/xmlenc#aes128-cbc [XMLEnc], 5.2.2 required
AES CBC 256 bit http://www.w3.org/2001/04/xmlenc#aes256-cbc [XMLEnc], 5.2.2 required
Key transport (1)
RSA Version 1.5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 [XMLEnc], 5.4.1