Using GOST 28147-89, GOST R 34.10, and GOST R 34.11 Algorithms for XML Security

Using GOST 28147-89, GOST R 34.10, and GOST R 34.11 Algorithms for XML Security "CRYPTO-PRO", LLC

18, Suschevsky Val str. Russian Federation 127018 Moscow +7 (916) 686 10 81 +74957804820 lse@cryptopro.ru http://www.cryptopro.ru

"CRYPTO-PRO", LLC

18, Suschevsky Val str. Russian Federation 127018 Moscow +7 (495) 780 4820 +74957804820 spv@CryptoPro.ru http://www.CryptoPro.ru

JSC "InfoTeCS"

build 1, 1/23, Staryj Petrovsko-Razumovsij pr. Moscow 127287 Russia +7 (495) 737-6192 +7 (495) 737-7278 Aleksandr.Chelpanov@infotecs.ru

Security GOST 28147-89 GOST R 34.11-94 GOST R 34.11-2012 GOST R 34.10-94 GOST R 34.10-2001 GOST R 34.10-2012 GOST 34.310-95 GOST 34.311-95 GOST 34.310-2004 This document specifies how to use Russian national cryptographic standards GOST 28147-89, GOST R 34.10 and GOST R 34.11 with XML Signatures, XML Encryption, WS-SecureConversation, WS-SecurityPolicy and WS-Trust. A number of Uniform Resource Identifiers (URIs) and XML elements are defined.

This document specifies how to use GOST R 34.10 digital signatures and public keys, GOST R 34.11 hash, GOST 28147-89 encryption algorithms with XML Signatures , XML Encryption , WS-SecureConversation , WS-SecurityPolicy and WS-Trust . This document uses both XML Schema (, ) (normative) and DTD (informational) to specify the corresponding XML structures. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Algorithms GOST R 34.10-2001, GOST R 34.11-94 and GOST 28147-89 have been developed by Russian Federal Agency of Governmental Communication and Information (FAGCI) and "All-Russian Scientific and Research Institute of Standardization". They are described in , ( and ) and . RECOMMENDED parameters for those algorithms are described in .

This specification makes no provision for an explicit version number in the syntax. If a future version is needed, it will use a different namespace. The XML namespace URI that MUST be used by implementations of this (dated) specification is: urn:ietf:params:xml:ns:cpxmlsec The following external XML namespaces are used in this specification (without line breaks; the choice of any namespace prefix is arbitrary and not semantically significant): http://www.w3.org/2000/09/xmldsig# Prefix: dsig Specification: http://www.w3.org/2001/04/xmlenc# Prefix: xenc Specification: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 Prefix: sp Specification: http://www.w3.org/ns/ws-policy Prefix: wsp Specification: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 Prefix: wsc Specification: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd Prefix: wsse Specification: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ Prefix: wst Specification: In the remaining sections of this document elements in the external namespaces are marked as such by using the namespace prefixes defined above.

The subsequent preamble is to be used with the XML Schema definitions given in the remaining sections of this document.

]]>

In order to include GOST XML-signature syntax, the following definition of the entity Key.ANY SHOULD replace the one in :

]]>

Object Identifiers (OIDs) are included in XML by the corresponding URN value as defined in .

The subsequent type is to be used to define algorithm parameters by OIDs: ]]>

This section specifies the details of how to use GOST algorithms with XML Signature Syntax and Processing and XML Encryption Syntax and Processing . It relies heavily on syntaxes and namespaces defined in and .

The identifier for the GOST R 34.11-94 digest algorithm is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 The dsig:DigestMethod node may contain a child node cpxmlsec:ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. cpxmlsec:ParametersR3411 node contains one OID specified in section 8.2 . If cpxmlsec:ParametersR3411 node is missing, the application should infer algorithm parameters from other sources. If the application omits cpxmlsec:ParametersR3411 node, it SHOULD use parameters defined by id-GostR3411-94-CryptoProParamSet (see Section 11.2 of ).

Schema Definition: ]]>

DTD Definition: ]]>

An example of a GOST R 34.11-94 dsig:DigestMethod node is: urn:oid:1.2.643.2.2.30.1< /cpxmlsec:ParametersR3411> ]]> A GOST R 34.11-94 digest is a 256-bit string. The content of the dsig:DigestValue element shall be the base64 encoding of this bit string viewed as a 32-octet octet stream.

The identifier for the GOST R 34.11-2012 digest algorithm with 256-bit output is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256

An example of a GOST R 34.11-2012 with 256-bit output dsig:DigestMethod node is: ]]> A GOST R 34.11-2012 digest in this case is a 256-bit string. The content of the dsig:DigestValue element shall be the base64 encoding of this bit string viewed as a 32-octet octet stream.

The identifier for the GOST R 34.11-2012 digest algorithm with 512-bit output is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-512

An example of a GOST R 34.11-2012 with 512-bit output dsig:DigestMethod node is: ]]> A GOST R 34.11-2012 digest in this case is a 512-bit string. The content of the dsig:DigestValue element shall be the base64 encoding of this bit string viewed as a 64-octet octet stream.

GOST R 34.11-94 can also be used in HMAC as described in section 6.3.1 of . Identifier: urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 The dsig:SignatureMethod node may contain a child node cpxmlsec:ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. cpxmlsec:ParametersR3411 node syntax and processing in this case are equivalent to the ones in dsig:DigestMethod case.

An example of a GOST R 34.11-94 HMAC disg:SignatureMethod node is: urn:oid:1.2.643.2.2.30.1< /cpxmlsec:ParametersR3411> ]]> The output of the GOST R 34.11-94 HMAC algorithm is ultimately the output of the GOST R 34.11-94 digest algorithm. This value shall be base64 encoded for the dsig:SignatureValue in the same straightforward fashion as the output of the digest algorithm in .

The input to the GOST R 34.10-2001 algorithm is the canonicalized representation of the dsig:SignedInfo element as specified in Section 3 of . The identifier for the GOST R 34.10-2001 signature algorithm is (without line break): urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411

An example of a GOST R 34.10-2001 dsig:SignatureMethod node is (without line break in attribute value): ]]> GOST R 34.10-2001 signature is a 64-octet value as described in section 2.2.2 of . The content of the dsig:SignatureValue element shall be the base64 [RFC4648] encoding of this value.

The input to the GOST R 34.10-2012 algorithm is the canonicalized representation of the dsig:SignedInfo element as specified in Section 3 of . The identifiers for the GOST R 34.10-2012 signature algorithm are (without line breaks): urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-512 Both identifiers refer to GOST R 34.11-2012 as digest algorithm. The first one denotes that the 256-bit output version of that algorithm is used, the second one corresponds to 512-bit output.

An example of a GOST R 34.10-2012 dsig:SignatureMethod node is (without line break in attribute value): ]]>

GOST R 34.10-2001 public key can be transmitted in cpxmlsec:GOSTKeyValue node. It is included in dsig:KeyValue node just like dsig:RSAKeyValue or xenc:DHKeyValue. cpxmlsec:GOSTKeyValue node consists of an optional child node cpxmlsec:PublicKeyParameters and a mandatory child node cpxmlsec:PublicKey. If cpxmlsec:PublicKeyParameters node is missing, the application should infer parameters from other sources.

Schema Definition: ]]>

DTD Definition: ]]> If the application omits cpxmlsec:PublicKeyParameters node, it SHOULD use parameters identified by DefaultPublicKeyParameters.

DefaultPublicKeyParameters: urn:oid:1.2.643.2.2.35.1< /cpxmlsec:publicKeyParamSet> urn:oid:1.2.643.2.2.30.1 urn:oid:1.2.643.2.2.31.1 ]]>

cpxmlsec:PublicKeyParameters node contains three OIDs: cpxmlsec:publicKeyParamSet, cpxmlsec:digestParamSet and optional cpxmlsec:encryptionParamSet. Parameter values corresponding to these OIDs can be found in .

Schema Definition: ]]>

DTD Definition: ]]>

Key agreement algorithm based on GOST R 34.10-2001 public keys (see Section 5 of ) involves the derivation of shared secret information using keys from the sender and recipient. The identifier for the key agreement algorithm based on GOST R 34.10-2001 is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:agree-gost2001

An example of a GOST R 34.10-2001-based key agreement AgreementMethod node is:

...

... ... ]]> The shared keying material for algorithm based on GOST R 34.10-2001 needed will be calculated as a result of function VKO GOST R 34.10-2001 (see Section 5.2 of ), which generates GOST KEK using two GOST R 34.10-2001 keypairs and UKM. xenc:KA-Nonce node of xenc:AgreementMethod contains base64 encoded 64-bits value of UKM, if UKM is used.

The key transport algorithm based on VKO GOST R 34.10-2001, specified in , is public key encryption algorithms, that MUST be used for key encryption/decryption only. The identifier for the key transport algorithm based on VKO GOST R 34.10-2001 is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001

An example of a VKO GOST R 34.10-2001-based key transport EncryptedKey node is: ... ... ]]> The CipherValue for such encrypted key is the base64 encoding of the DER encoding of a GostR3410-KeyTransport structure (see section 4.2.1 of ).

The identifier for the GOST 28147-89 symmetric encryption algorithm is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 The xenc:EncryptionMethod node may contain a child node cpxmlsec:Parameters28147 specifying parameters for GOST 28147-89 algorithm. cpxmlsec:Parameters28147 specifies the set of corresponding Gost28147-89-ParamSetParameters (see Section 8.1 of ). Encryption mode is specified by mode parameter of Gost28147-89-ParamSetParameters structure. CFB and CNT modes are RECOMMENDED to use. If cpxmlsec:Parameters28147 node is missing, the application should infer algorithm parameters from other sources. If the application omits cpxmlsec:Parameters28147 node, it SHOULD use parameters defined by id-Gost28147-89-CryptoPro-A-ParamSet (see Section of 10.2 [CPALGS]).

Schema Definition: ]]>

DTD Definition: ]]>

An example of a GOST 28147-89 xenc:EncryptionMethod node is: urn:oid:1.2.643.2.2.31.1< /cpxmlsec:Parameters28147> ]]> 256-bit key, 64-bit Initialization Vector (IV), and optional parameters are used in GOST 28147-89 encryption algorithm. The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded.

The identifier for the GOST 28147-89 authenticated encryption algorithm is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147aead The xenc:EncryptionMethod node may contain a child node cpxmlsec:Parameters28147 specifying parameters for GOST 28147-89 algorithm. If the application omits cpxmlsec:Parameters28147 node, it SHOULD use parameters defined by id-tc26-gost-28147-param-Z.

An example of a GOST 28147-89 AEAD xenc:EncryptionMethod node is: urn:oid:1.2.643.7.1.2.5.1.1< /cpxmlsec:Parameters28147> ]]> 256-bit key, 64-bit Initialization Vector (IV), and optional parameters are used in GOST 28147-89 authenticated encryption algorithm. The resulting cipher text is prefixed by the IV and suffixed by the MAC. Standard XML encryption padding, id-Gost28147-89-CryptoPro-KeyMeshing, imitovstavka and CNT mode should be used during encryption. If included in XML output, it is then base64 encoded.

Symmetric Key Wrap algorithms considered in this section are shared secret key encryption algorithms that MUST be used for symmetric keys encryption/decryption only.

The GOST 28147-89 Key Wrap algorithm wraps (encrypts) a key (the wrapped key, WK) under a GOST 28147-89 Key Wrap (specified in sections 6.1, 6.2 of ). Note: This algorithm MUST NOT be used without key agreement algorithm, because such WK is constant for every wrapping-encrypting pair. Encrypting many different keys with the same constant WK may reveal that WK. The only key agreement algorithm possible to use with GOST 28147-89 Key Wrap defined by this specification is a GOST R 34.10-2001-based key agreement (see ). The identifier for the GOST 28147-89 Key Wrap algorithm is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-gost The CipherValue for such wrapped key is the base64 encoding of the DER encoding of a GostR3410-KeyWrap structure.

ASN.1 structure:

An example of a GOST 28147-89 Key Wrap EncryptedData node is:

...

... ... ... ... ]]> Gost28147-89-KeyWrapParameters is described in section 4.1.1 of . The xenc:KA-Nonce node value of the xenc:AgreementMethod node MUST be used as ukm. The resulting wrapped key (WK) is placed in the Gost28147-89-EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the Gost28147-89-EncryptedKey macKey field. ukm field of Gost28147-89-KeyWrapParameters MUST be absent.

The CryptoPro Key Wrap algorithm wraps (encrypts) a key (wrapped key, WK) under a CryptoPro Key Wrap (specified in sections 6.3, 6.4 of ). The identifier for the CryptoPro Key Wrap algorithms is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp The CipherValue for such wrapped key is the base64 encoding of the DER encoding of a GostR3410-KeyWrap structure (see ).

An example of a CryptoPro Key Wrap EncryptedData node is: John Smith ... ... ]]> The resulting wrapped key (WK) is placed in the Gost28147-89-EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the Gost28147-89-EncryptedKey macKey field. If CryptoPro Key Wrap algorithm is combined with Key Agreement Algorithm, the xenc:KA-Nonce node value of the xenc:AgreementMethod node MUST be used as ukm. ukm field of Gost28147-89-KeyWrapParameters type must be absent. Note: The only key agreement algorithm possible to use with CryptoPro Key Wrap defined by this specification is a GOST R 34.10-2001-based key agreement (see ). If CryptoPro Key Wrap algorithm is not combined with Key Agreement Algorithm, ukm field of Gost28147-89-KeyWrapParameters type MUST be present.

This section specifies the details of how to use GOST algorithms with WS-SecureConversation , WS-SecurityPolicy and WS-Trust .

This specification defines a new possible value for an [Algorithm Suite] property of a Security Binding (see section 6.1 of ). The new value is BasicGost. BasicGost Algorithm Suite defines the following values for operations and properties (without line breaks in URIs): [Sym Sig] urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 [Asym Sig] urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411 [Dig] urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 [Enc] urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 [Sym KW] urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp [Asym KW] urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 [Comp Key] urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 [Enc KD] urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 [Sig KD] urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 [Min SKL] 256 [Max SKL] 256 [Min AKL] 512 [Max AKL] 512 Note: For definition of [Comp Key], [Enc KD] and [Sig KD] algorithm see To indicate a requirement to use GOST Algorithm Suite defined above conforming implementations MUST place cpxmlsec:BasicGost node in sp:AlgorithmSuite Assertion (see section 7.1 of ).

Schema Definition: ]]>

DTD Definition: ]]>

An example of a GOST Algorithm Suite in sp:AlgorithmSuite Assertion is: ]]>

This specification defines a new possible value for an Algorithm attribute of a wsc:DerivedKeyToken node (see section 7 of ). The new key derivation algorithm identifier is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411

An example of a GOST Key Derivation Algorithm in wsc:DerivedKeyToken node is: ... ... ]]> GOST Key Derivation Algorithm uses a pseudo-random function P_GOSTR3411 (see section 4 of ) to derive keys just like a P_SHA-1 function is used in (see section 7).

This specification defines a new possible value for a wst:ComputedKey node (see section 4.4.4 of ). The new computed key mechanism identifier is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411

An example of a GOST Computed Key Mechanism in wst:ComputedKey node (without line breaks) is: urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 ]]> GOST Computed Key Mechanism uses a pseudo-random function P_GOSTR3411 (see section 4 of ) to compute a key just like a P_SHA-1 function is used in (see section 4.4.4). It is REQUIRED that EntREQ and EntRES are strings of length 256 bits.

This specification defines how to use WS-Trust () to perform TLS Handshake (see ) and establish secure session for GOST Algorithm Suite. WS-Trust can be used to do TLS Handshake as specified in . The outcome of the protocol under discussion is a new session key issued using a secure session established by TLS Handshake. Issued session key is intended to secure further communication by means of WS-Security (). If application is required to use GOST Algorithm Suite after performing TLS Handshake by WS-Trust it MUST use one of GOST 28147-89 Cipher Suites for TLS (see ). The main flow of TLS Negotiation over WS-Trust defined in this specification complies with , but there are a few differences specified below that MUST be obeyed. The paragraph R4305 (see section 4.3 of ) MUST be replaced with the following text: The responder is responsible for issuing the key associated with the TLSNego session. If the initiator requested properties for the generated key (e.g. key size) in the initial RST message, the generated key SHOULD match those requirements. The issued key MUST be communicated back to the initiator using the wst:RequestedProofToken element and MUST be protected using CryptoPro Key Wrap algorithm (see section 6.3 of ) where server_write_key (see section 6.3 of ) is a wrapping key. Wrapped key is contained in the ...]]> elements of the xenc:EncryptedKey. GOST R 34.11-94 and P_GOSTR3411 algorithms MUST be used instead of SHA1 and PSHA1 algorithms correspondingly to compute authenticator (see section 4.9 of ).

Conforming applications MUST use unique values for ukm and iv. Recipients MAY verify that ukm and iv specified by the sender are unique. Applications SHOULD verify signature values, subject public keys and algorithm parameters to conform to , standard before using them. Cryptographic algorithm parameters affect algorithm strength. Using parameters not listed in is NOT RECOMMENDED (see the Security Considerations section of ). Using the same key for signature and key derivation is NOT RECOMMENDED. It is NOT RECOMMENDED to use XML encryption without XML signature or HMAC.

This document uses URNs to describe XML namespaces and XML schemata conforming to a registry mechanism described in . IANA has registered two URI assignments.

URI: urn:ietf:params:xml:ns:cpxmlsec Registrant Contact: Mikhail V. Pavlov CRYPTO-PRO, Ltd. 16/5, Suschevskij val Moscow, 127018 Russia Phone: +7 (495) 780 4820 Fax: +7 (495) 660 2330 Email: pav@CryptoPro.ru URI: http://www.CryptoPro.ru XML: None. Namespace URIs do not represent an XML specification.

URI: urn:ietf:params:xml:schema:cpxmlsec Registrant Contact: Mikhail V. Pavlov CRYPTO-PRO, Ltd. 16/5, Suschevskij val Moscow, 127018 Russia Phone: +7 (495) 780 4820 Fax: +7 (495) 660 2330 Email: pav@CryptoPro.ru URI: http://www.CryptoPro.ru XML: The XML can be found in .

&xml-schema-1; &xml-schema-2; &xml-ns; &rfc3986; &rfc4648; &rfc3688; &hmac; &keywords; &xmlenc-core; &xmldsig; &cpalgs; &cppk; &cpcms; &gost28147; &gostr341001; &gostr341194; &gost3431004; &gost3431195; &ws-security; &ws-secureconversation; &ws-securitypolicy; &ws-policy; &ws-trust; &ws-trust-tls; &tls; &cptls; &asn1; &xml-core; &urnoid; &rfc4134;

Examples here are stored in the same format as the examples in and can be extracted using the same program. If you want to extract without the program, copy all the lines between the "|>" and "|<" markers, remove any page breaks, and remove the "|" in the first column of each line. The result is a valid Base64 blob that can be processed by any Base64 decoder.

This sample contain the signed XML document using the sample certificate from Section 4.2 of .

The authors wish to thank: Microsoft Corporation Russia for provided information about company products and solutions, and also for technical consulting in PKI. Our colleague Grigorij S. Chudov for writing the first version of this document.