Using GOST 28147-89, GOST R 34.10-2001, and
GOST R 34.11-94 Algorithms for XML Security
CRYPTO-PRO, Ltd.
16/5, Suschevskij valMoscow127018Russia+7 (495) 780 4820+7 (495) 660 2330lse@CryptoPro.ruhttp://www.CryptoPro.ru
CRYPTO-PRO, Ltd.
16/5, Suschevskij valMoscow127018Russia+7 (495) 780 4820+7 (495) 660 2330spv@CryptoPro.ruhttp://www.CryptoPro.ru
CRYPTO-PRO, Ltd.
16/5, Suschevskij valMoscow127018Russia+7 (495) 780 4820+7 (495) 660 2330cav@CryptoPro.ruhttp://www.CryptoPro.ru
Security
GOST 28147-89GOST R 34.10-94GOST R 34.11-94GOST R 34.10-2001GOST 34.310-95GOST 34.311-95GOST 34.310-2004
This document specifies how to use Russian national
cryptographic standards GOST 28147-89,
GOST R 34.10-2001 and GOST R 34.11-94
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-2001 digital signatures and
public keys, GOST R 34.11-94 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.
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.
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.
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.
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
<xenc:CipherData><xenc:CipherValue>...</xenc:CipherValue></xenc:CipherData>
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 Part 1: Structures Second EditionUniversity of Edinburghht@cogsci.ed.ac.ukOracle CorporationDavid.Beech@oracle.comCommerce Onemurray@muzmo.comLotus Development CorporationNoah_Mendelsohn@lotus.comXML Schema Part 2: Datatypes Second EditionKaiser Permanente, for Health Level SevenPaul.V.Biron@kp.orgMicrosoft (formerly of IBM)ashokma@microsoft.comNamespaces in XML (Second Edition)Textualitytbray@textuality.comContivo, Inc.dmh@contivo.comMicrosoftandrewl@microsoft.comUniversity of Edinburgh and Markup Technology Ltdrichard@cogsci.ed.ac.ukUniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/
Applications
uniform resource identifierURIURLURNWWWresource
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.HMAC: Keyed-Hashing for Message AuthenticationIBM, T.J. Watson Research CenterP.O.Box 704Yorktown HeightsNY10598UShugo@watson.ibm.comUniversity of California at San Diego, Dept of Computer Science and Engineering9500 Gilman DriveMail Code 0114La JollaCA92093USmihir@cs.ucsd.eduIBM T.J. Watson Research CenterP.O.Box 704Yorktown HeightsNY10598UScanetti@watson.ibm.comThis document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
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
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
XML Encryption Syntax and ProcessingMotoroladee3@torque.pothole.comW3Creagle@w3.org(Extensible Markup Language) XML-Signature Syntax and
ProcessingThis document specifies XML (Extensible Markup Language) digital
signature processing rules and syntax. [STANDARDS TRACK]Additional Cryptographic Algorithms for Use
with GOST 28147-89, GOST R 34.10-94,
GOST R 34.10-2001, and GOST R 34.11-94 AlgorithmsThis document describes the cryptographic
algorithms and parameters supplementary to the
original GOST specifications, GOST 28147-89,
GOST R 34.10-94, GOST R 34.10-2001, and
GOST R 34.11-94,
for use in Internet applications. This memo provides
information for the Internet community.Using the GOST R 34.10-94,
GOST R 34.10-2001,
and GOST R 34.11-94 Algorithms with the Internet
X.509 Public Key Infrastructure Certificate and CRL
ProfileThis document supplements RFC 3279. It
describes encoding formats, identifiers, and
parameter formats for the algorithms
GOST R 34.10-94, GOST R 34.10-2001, and
GOST R 34.11-94 for
use in Internet X.509 Public Key Infrastructure
(PKI). [STANDARDS TRACK]Using the GOST 28147-89, GOST R 34.11-94,
GOST R 34.10-94, and GOST R 34.10-2001 Algorithms
with Cryptographic Message Syntax (CMS)This document describes the conventions for
using the cryptographic algorithms GOST 28147-89,
GOST R 34.10-94,
GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax
(CMS). The CMS is used for digital signature,
digest, authentication, and encryption of arbitrary
message contents. [STANDARDS TRACK]Cryptographic Protection for Data Processing
System, Gosudarstvennyi Standard of USSR (In
Russian)
Government Committee of the USSR for Standards
?????Information technology. Cryptographic Data
Security.Signature and verification processes of
[electronic] digital signature, Gosudarstvennyi
Standard of Russian Federation (In Russian)
Government Committee of the Russia for Standards
Information technology. Cryptographic Data
Security. Hashing function, Gosudarstvennyi
Standard of Russian Federation (In Russian)
Government Committee of the Russia for Standards
Information technology. Cryptographic Data
Security. Formation and verification processes of
(electronic) digital signature based on Asymmetric
Cryptographic Algorithm (In Russian) Council for Standardization,
Metrology and Certification of the Commonwealth of
Independence States (EASC), Minsk
Information technology. Cryptographic Data
Security. Cashing function (In Russian) Council for Standardization,
Metrology and Certification of the Commonwealth of
Independence States (EASC), Minsk
Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)IBMMicrosoftWS-SecureConversation 1.3IBMMicrosoftWS-SecurityPolicy 1.2IBMMicrosoftWeb Services Policy 1.5 - FrameworkMicrosoftBEA SystemsNokiaIBMwebMethodsLayer 7 TechnologiesSAPWS-Trust 1.3IBMMicrosoftApplication Note: Using WS-Trust for TLS HandshakeMicrosoftMicrosoftMicrosoftMicrosoftMicrosoftIBMIBMIBMMicrosoftThe Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS TRACK]GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)This document is intended to register new cipher suites for the Transport Layer Security (TLS) protocol, according to the procedure specified in TLS Protocol standards. These cipher suites are based on Russian national cryptographic standards - GOST R 34.10-94 and GOST R 34.10-2001 public keys, GOST 28147-89 encryption algorithm and GOST R 34.11-94 digest algorithm.Specification of Abstract Syntax Notation One (ASN.1)
International International Telephone and Telegraph
Consultative Committee
Extensible Markup Language (XML) 1.0 (Fourth Edition)Textuality and Netscapetbray@textuality.comMicrosoftjeanpa@microsoft.comUniversity of Illinois at Chicago and Text Encoding Initiativecmsmcq@uic.eduSun Microsystemseve.maler@east.sun.comA URN Namespace of Object IdentifiersThis document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.Examples of S/MIME MessagesThis document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This memo provides information for the Internet community.
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.