From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2802.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc2802.txt (limited to 'doc/rfc/rfc2802.txt') diff --git a/doc/rfc/rfc2802.txt b/doc/rfc/rfc2802.txt new file mode 100644 index 0000000..efabec3 --- /dev/null +++ b/doc/rfc/rfc2802.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group K. Davidson +Request for Comments: 2802 Differential +Category: Informational Y. Kawatsura + Hitachi + April 2000 + + + Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + A syntax and procedures are described for the computation and + verification of digital signatures for use within Version 1.0 of the + Internet Open Trading Protocol (IOTP). + +Acknowledgment + + This document is based on work originally done on general XML digital + signatures by: + + Richard Brown of GlobeSet, Inc. + + Other contributors to the design of the IOTP DSIG DTD include, in + alphabetic order: + + David Burdett, Commerce One + Andrew Drapp, Hitachi + Donald Eastlake 3rd, Motorola, Inc. + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 1] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +Table of Contents + + 1. Introduction............................................3 + 2. Objective and Requirements..............................3 + 3. Signature Basics........................................3 + 3.1 Signature Element......................................3 + 3.2 Digest Element.........................................4 + 3.3 Originator and Recipient Information Elements..........5 + 3.4 Algorithm Element......................................5 + 4. Detailed Signature Syntax...............................6 + 4.1 Uniform Resource Names.................................6 + 4.2 IotpSignatures.........................................6 + 4.3 Signature Component....................................6 + 4.3.1 Signature............................................6 + 4.3.2 Manifest.............................................7 + 4.3.3 Algorithm............................................9 + 4.3.4 Digest...............................................9 + 4.3.5 Attribute...........................................10 + 4.3.6 OriginatorInfo......................................11 + 4.3.7 RecipientInfo.......................................11 + 4.3.8 KeyIdentifier.......................................12 + 4.3.9 Parameter...........................................13 + 4.4 Certificate Component.................................13 + 4.4.1 Certificate.........................................13 + 4.4.2 IssuerAndSerialNumber...............................14 + 4.5 Common Components.....................................15 + 4.5.1 Value...............................................15 + 4.5.2 Locator.............................................15 + 5. Supported Algorithms...................................16 + 5.1 Digest Algorithms.....................................16 + 5.1.1 SHA1................................................16 + 5.1.2 DOM-HASH............................................17 + 5.2 Signature Algorithms..................................17 + 5.2.1 DSA.................................................17 + 5.2.2 HMAC................................................18 + 5.2.3 RSA.................................................20 + 5.2.4 ECDSA...............................................20 + 6. Examples...............................................21 + 7. Signature DTD..........................................23 + 8. Security Considerations................................25 + References................................................26 + Authors' Addresses........................................28 + Full Copyright Statement..................................29 + + + + + + + + +Davidson & Kawatsura Informational [Page 2] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +1. Introduction + + The Internet Open Trading Protocol (IOTP) provides a payment system + independent interoperable framework for Internet commerce as + documented in [RFC 2801]. All IOTP messages are XML documents. XML, + the Extensible Markup Language [XML], is a syntactical standard + promulgated by the World Wide Web Consortium. XML is intended + primarily for structuring data exchanged and served over the World + Wide Web. + + Although IOTP assumes that any payment system used with it provides + its own security, there are numerous cases where IOTP requires + authentication and integrity services for portions of the XML + messages it specifies. + +2. Objective and Requirements + + This document covers how digital signatures may be used with XML + documents to provide authentication and tamper-proof protocol + messages specifically for Version 1.0 of the IOTP protocol. The + reader should recognize that an effort towards general XML digital + signatures exists but is unlikely to produce its final result in time + for IOTP Version 1.0. Future versions of IOTP will probably adopt by + reference the results of this general XML digital signature effort. + + The objective of this document is to propose syntax and procedures + for the computation and verification of digital signatures applicable + to Version 1.0 IOTP protocol messages, providing for: + + -- Authentication of IOTP transactions + -- Provide a means by which an IOTP message may be made "tamper- + proof", or detection of tampering is made evident + -- Describe a set of available digest and signature algorithms at + least one of which is mandatory to implement for interoperability + -- Easily integrate within the IOTP 1.0 Specification + -- Provide lightweight signatures with minimal redundancy + -- Allow signed portions of IOTP message to be "forwarded" to another + trading roles with different signature algorithms than the + original recipient + +3. Signature Basics + +3.1 Signature Element + + This specification consists primarily of the definition of an XML + element known as the Signature element. This element consists of two + sub-elements. The first one is a set of authenticated attributes, + known as the signature Manifest, which comprises such things as a + + + +Davidson & Kawatsura Informational [Page 3] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + unique reference to the resources being authenticated and an + indication of the keying material and algorithms being used. The + second sub-element consists of the digital signature value. + + + + (resource information block) + (originator information block) + (recipient information block) + (other attributes) + (signature algorithms information block) + + + (encoded signature value) + + + + The digital signature is not computed directly from the pieces of + information to be authenticated. Instead, the digital signature is + computed from a set of authenticated attributes (the Manifest), which + include references to, and a digests of, those pieces of information. + + The authentication is therefore "indirect". + +3.2 Digest Element + + The Digest element consists of a unique and unambiguous reference to + the XML resources being authenticated. It is constructed of a locator + and the digest value data itself. The Digest algorithm is referred to + indirectly via a DigestAlgorithmRef, so that Digest algorithms may be + shared by multiple resources. + + + + + (Digest value) + + + + The resource locator is implemented as a simple XML Link [XLink]. + This not only provides a unique addressing scheme for internal and + external resources, but also facilitates authentication of composite + documents. + + + + + + + + +Davidson & Kawatsura Informational [Page 4] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +3.3 Originator and Recipient Information Elements + + The purpose of the Originator and Recipient information elements is + to provide identification and keying material for these respective + parties. + + + (identification information block) + (keying material information block) + + + + (identification information block) + (keying material information block) + + + The actual content of these two elements depends on the + authentication scheme being used and the existence or non-existence + of a prior relationship between the parties. In some circumstances, + it may be quite difficult to distinguish between identification and + keying material information. A unique reference to a digital + certificate provides for both. This may also stand true for an + account number when a prior relationship exists between the parties. + + The Originator information element is mandatory. Depending on the + existence or non-existence of a prior relationship with the + recipient, this block either refers to a public credential such as a + digital certificate or displays a unique identifier known by the + recipient. + + The Recipient information element may be used when a document + contains multiple signature information blocks, each being intended + for a particular recipient. A unique reference in the Recipient + information block helps the recipients identify their respective + Signature information block. + + The Recipient information element may also be used when determination + of the authentication key consists of a combination of keying + material provided by both parties. This would be the case, for + example, when establishing a key by means of Diffie Hellman + [Schneier] Key Exchange algorithm. + +3.4 Algorithm Element + + The Algorithm element is a generalized place to put any type of + algorithm used within the signed IOTP message. The Algorithm may be a + Signature algorithm or a Digest algorithm. Each algorithm contains + parameters specific to the algorithm used. + + + +Davidson & Kawatsura Informational [Page 5] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + + (algorithm information block) + + + Algorithms are required to contain an ID which allows for indirect + reference to them from other places in the XML signature. + +4. Detailed Signature Syntax + +4.1 Uniform Resource Names + + To prevent potential name conflicts in the definition of the numerous + type qualifiers considered herein, this specification uses Uniform + Resource Names [RFC 2141]. + +4.2 IotpSignatures + + The IotpSignatures element is the top-level element in an IOTP + signature block. It consists of a collection of Signature elements, + and an optional set of Certificates. + + + + + Content Description + + Signature: A collection of Signature elements. + + Certificate: Zero or more certificates used for signing + + Attributes Description + + ID: Element identifier that may be used to reference the entire + Signature element from a Resource element when implementing + endorsement. + +4.3 Signature Component + +4.3.1 Signature + + The Signature element constitutes the majority of this specification. + It is comprised of two sub-elements. The first one is a set of + attributes, known as the Manifest, which actually constitutes the + authenticated part of the document. The second sub-element consists + of the signature value or values. + + + + + +Davidson & Kawatsura Informational [Page 6] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + The Value element contained within the Signature element is the + encoded form of the signature of the Manifest element, and thus + provides the verification of the Manifest. + + The process for generating the signed value is a multi-step process, + involving a canonicalization algorithm, a digest algorithm, and a + signature algorithm. + + First, the Manifest is canonicalized with an algorithm specified + within the Algorithm element of the Manifest. The canonicalized form + removes any inconsistencies in white space introduced by XML parsing + engines. + + This canonicalized form is then converted into a digest form which + uniquely identifies the canonicalized document. Any slight + modification in the original document will result in a very different + digest value. + + Finally, the digest is then signed using a public/symmetric key + algorithm which digitally stamps the digest (with the certificate of + the signer if available). The final signed digest is the value which + is stored within the Signature's Value element. + + + + + Content Description + + Manifest: A set of attributes that actually constitutes the + authenticated part of the document. + + Value: One or more encodings of signature values. Multiple values + allow for a multiple algorithms to be supported within a single + signature component. + + Attributes Description + + ID: Element identifier that may be used to reference the Signature + element from a Resource element when implementing endorsement. + +4.3.2 Manifest + + The Manifest element consists of a collection of attributes that + specify such things as references to the resources being + authenticated and an indication of the keying material and algorithms + to be used. + + + + +Davidson & Kawatsura Informational [Page 7] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + + + Content Description + + Algorithm: A list of algorithms used for signing, digest computation, + and canonicalization. + + Digest: A list of digests of resources to be authentication and + signed. + + Attribute: Optional element that consists of a collection of + complementary attributes to be authenticated. + + OriginatorInfo: Element that provides identification and keying + material information related to the originator. + + RecipientInfo: Optional element that provides identification and + keying material information related to the recipient. + + Attributes Description + + LocatorHrefBase: The LocatorHrefBase provides a similar construct to + the HTML HREFBASE attribute and implicitly sets all relative URL + references within the Manifest to be relative to the HrefBase. For + example, the IOTP Manifest may contain: + + + + And subsequent Locators may be: + + + + An implementation should concatenate the two locator references with + "#" to create the entire URL. See definition of the Locator attribute + on the Digest element for more detail. + + + + + + + +Davidson & Kawatsura Informational [Page 8] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +4.3.3 Algorithm + + This specification uses an Algorithm data type which indicates many + different types of algoirithms. The Algorithm element allows for + specification of sub-algorithms as parameters of the primary + algorithm. This is performed via a parameter within the algorithm + that provides a reference to another Algorithm. An example of this is + shown in the Parameter section. + + + + + Content Description + + Parameter: The contents of an Algorithm element consists of an + optional collection of Parameter elements which are specified on a + per algorithm basis. + + Attributes Description + + ID: The ID of the algorithm is used by the Digest and RecipientInfo + to refer to the signing or digest algorithm used. + + type: The type of algorithm, either a digest or signature. This is + implied by the element to which the algorithm is referred. That is, + if the DigestAlgorithmRef refers to an algorithm, it is implicit by + reference that the targeted algorithm is a digest. + + name: The type of the algorithm expressed as a Uniform Resource + Name. + +4.3.4 Digest + + The Digest element consists of the fingerprint of a given resource. + This element is constructed of two sub-elements. This first one + indicates the algorithm to be used for computation of the + fingerprint. The second element consists of the fingerprint value. + + + + + + + + + +Davidson & Kawatsura Informational [Page 9] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + Content Description + + Locator: Contains a "HREF" or URL Locator for the resources to be + fingerprinted. For use within IOTP a "scheme" with the value "iotp" + may be used with the following structure: + + 'iotp:#'. + + This should be interpreted as referring to an element with an ID + attribute that matches in any IOTP Message that has a + TransRefBlk Block with an IotpTransId that matches . + + If the LocatorHrefBase attribute is set on the Manifest element of + which this Digest element is a child, then concatenate the value of + the LocatorHrefBase attribute with the value of the Locator attribute + before identifying the element that is being referred to. + + If the LocatorHrefBase attribute is omitted, + should be interpreted as the current IotpTransId, which is included + in the IOTP message which contains the Manifest component. + + Value: Encoding of the fingerprint value. + + Attributes Description + + DigestAlgorithmRef: ID Reference of algorithm used for computation of + the digest. + +4.3.5 Attribute + + The Attribute element consists of a complementary piece of + information, which shall be included in the authenticated part of the + document. This element has been defined primarily for enabling some + level of customization in the signature element. This is the area + where a specific IOTP implementation may include custom attributes + which must be authenticated directly. An Attribute element consists + of a value, a type, and a criticality. + + At this time, no IOTP specific attributes are specified. + + + + + + + + +Davidson & Kawatsura Informational [Page 10] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + Content Description + + ANY: The actual value of an attribute depends solely upon its type. + + Attributes Description + + type: Type of the attribute. + + critical: Boolean value that indicates if the attribute is critical + (true) or not (false). A recipient shall reject a signature that + contains a critical attribute that he does not recognize. However, an + unrecognized non-critical attribute may be ignored. + +4.3.6 OriginatorInfo + + The OriginatorInfo element is used for providing identification and + keying material information for the originator. + + + + + Content Description + + ANY: Identification and keying material information may consist of + ANY construct. Such a definition allows the adoption of + application-specific schemes. + + Attributes Description + + OriginatorRef: A reference to the IOTP Org ID of the originating + signer. + +4.3.7 RecipientInfo + + The RecipientInfo element is used for providing identification and + keying material information for the recipient. This element is used + either for enabling recognition of a Signature element by a given + recipient or when determination of the authentication key consists of + the combination of keying material provided by both the recipient and + the originator. + + The RecipientInfo attributes provide a centralized location where + signatures, algorithms, and certificates intended for a particular + recipient are specified. + + + + + +Davidson & Kawatsura Informational [Page 11] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + The signature certificate reference ID MUST point to a certificate + object. + + + + + Content Description + + ANY: Identification and keying material information may consist of + ANY construct. + + Attributes Description + + SignatureAlgorithmRef: A reference to the signature algorithm used to + sign the SignatureValueRef intended for this recipient. The signature + algorithm reference ID MUST point to a signature algorithm within the + Manifest. + + SignatureValueRef: A reference to the signature value for this + recipient. The signature value reference ID MUST point to a value + structure directly included within a Manifest. This reference can be + omitted if the application can specify the digest value. + + SignatureCertRef: A reference to the certificate used to sign the + Value pointed to by the SignatureValueRef. This reference can be + omitted if the application can identify the certificate. + + RecipientRefs: A list of references to the IOTP Org ID of the + recipients this signature is intended for. + +4.3.8 KeyIdentifier + + The key identifier element can identify the shared public/symmetric + key identification between parties that benefit from a prior + relationship. This element can be included in the ReceipientInfo + Element. + + + + + + + + +Davidson & Kawatsura Informational [Page 12] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +4.3.9 Parameter + + A Parameter element provides the value of a particular algorithm + parameter, whose name and format have been specified for the + algorithm considered. + + + + + For IOTP 1.0, the following parameter type is standardized: + "AlgorithmRef". + + An AlgorithmRef contains an ID of a "sub-Algorithm" used when + computing a sequence of algorithms. For example, a signature + algorithm actually signs a digest algorithm. To specify a chain of + algorithms used to compute a signature, AlgorithmRef parameter types + are used in the following manner: + + + A2 + + + + + A1 + + + Content Description + + ANY: The contents of a Parameter element consists of ANY valid + construct, which is specified on a per algorithm per parameter basis. + + Attributes Description + + type: The type of the parameter expressed as a free form string, + whose value is specified on a per algorithm basis. + +4.4 Certificate Component + +4.4.1 Certificate + + The Certificate element may be used for either providing the value of + a digital certificate or specifying a location from where it may be + retrieved. + + + + + +Davidson & Kawatsura Informational [Page 13] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + + + + Content Description + + IssuerAndSerialNumber: Unique identifier of this certificate. This + element has been made mandatory is order to prevent unnecessary + decoding during validation of a certificate chain. This feature also + helps certificates caching, especially when the value is not directly + provided. + + Value: Encoding of the certificate value. The actual value to be + encoded depends upon the type of the certificate. + + Locator: XML link element that could be used for retrieving a copy of + the digital certificate. The actual value being returned by means of + this locator depends upon the security protocol being used. + + Attributes Description + + ID: Element identifier that may be used to reference the Certificate + element from a RecipientInfo element. + + type: Type of the digital certificate. This attribute is specified as + a Universal Resource Name. Support for the X.509 version 3 + certificate [X.509] is mandatory in this specification if the + Certificate element is used. The URN for such certificates is + "urn:X500:X509v3". + +4.4.2 IssuerAndSerialNumber + + The IssuerAndSerialNumber element identifies a certificate, and + thereby an entity and a public key, by the name of the certificate + issuer and an issuer-specific certificate identification. + + + + + + + + + + +Davidson & Kawatsura Informational [Page 14] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + Attributes Description + + issuer: Name of the issuing certification authority. See [RFC 2253] + for RECOMMENDED syntax. + + number: Issuer-specific certificate identification. + +4.5 Common Components + +4.5.1 Value + + A value contains the "raw" data of a signature or digest algorithm, + usually in a base-64 encoded form. See [RFC 2045] for algorithm used + to base-64 encode data. + + + + + Content Description + + PCDATA: Content value after adequate encoding. + + Attributes Description + + encoding: This attribute specifies the decoding scheme to be + employed for recovering the original byte stream from the content of + the element. This document recognizes the following two schemes: + + none: the content has not been subject to any particular encoding. + This does not preclude however the use of native XML encoding such as + CDATA section or XML escaping. + + base64: The content has been encoded by means of the base64 encoding + scheme. + +4.5.2 Locator + + The Locator element consists of simple XML link [XLink]. This + element allows unambiguous reference to a resource or fragment of a + resource. + + + + + + +Davidson & Kawatsura Informational [Page 15] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + Attributes Description + + xml:link: Required XML link attribute that specifies the nature of + the link (simple in this case). + + href: Locator value that may contains either a URI [RFC 2396], a + fragment identifier, or both. + +5. Supported Algorithms + + The IOTP specification 1.0 requires the implementation of the DSA, + DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also + recommended. + +5.1 Digest Algorithms + + This specification contemplates two types of digest algorithms, both + of which provide a digest string as a result: + + Surface string digest algorithms + + These algorithms do not have any particular knowledge about the + content being digested and operate on the raw content value. Any + changes in the surface string of a given content affect directly the + value of the digest being produced. + + Canonical digest algorithms + + These algorithms have been tailored for a particular content type and + produce a digest value that depends upon the core semantics of such + content. Changes limited to the surface string of a given content do + not affect the value of the digest being produced unless they affect + the core semantic. + +5.1.1 SHA1 + + Surface string digest algorithm designed by NIST and NSA for use with + the Digital Signature Standard. This algorithm produces a 160-bit + hash value. This algorithm is documented in NIST FIPS Publication + 180-1 [SHA1]. + + This algorithm does not require any parameter. + + The SHA1 URN used for this specification is "urn:nist-gov:sha1". + + + + + + + +Davidson & Kawatsura Informational [Page 16] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +5.1.2 DOM-HASH + + XML canonical digest algorithm proposed by IBM Tokyo Research + Laboratory. This algorithm operates on the DOM representation of the + document and provides an unambiguous means for recursive computation + of the hash value of the nodes that constitute the DOM tree [RFC + 2803]. This algorithm has many applications such as computation of + digital signature and synchronization of DOM trees. However, because + the hash value of an element is computed from the hash values of the + inner elements, this algorithm is better adapted to small documents + that do not require one-pass processing. + + As of today, this algorithm is limited to the contents of an XML + document and, therefore, does not provide for authentication of the + internal or external subset of the DTD. + + The DOM-HASH algorithm requires a single parameter, which shall + include a surface string digest algorithm such as SHA1. + + The DOM-HASH URN used for this specification is "urn:ibm-com:dom- + hash". + + The DOM-HASH uses a surface-string digest algorithm for computation + of a fingerprint. The SHA1 is recommended in this specification. + + Example + + + + + P.3 + + +5.2 Signature Algorithms + + This specification uses the terminology of 'digital signature' for + qualifying indifferently digital signature and message authentication + codes. Thus, the signature algorithms contemplated herein include + public key digital signature algorithms such as ECDSA and message + authentication codes such as HMAC [RFC 2104]. + +5.2.1 DSA + + Public-key signature algorithm proposed by NIST for use with the + Digital Signature Standard. This standard is documented in NIST FIPS + Publication 186 [DSS] and ANSI X9.30 [X9.30]. + + + + + +Davidson & Kawatsura Informational [Page 17] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + The DSA algorithm requires a single parameter, which includes the + canonical digest algorithm to be used for computing the fingerprint + of the signature Manifest. + + The DSA URN used in this specification is "urn:nist-gov:dsa". + + The DSA uses a canonical or surface-string digest algorithm for + computation of the Manifest fingerprint. The DOM-HASH is recommended + in this specification. + + Signature Value Encoding: + + The output of this algorithm consists of a pair of integers usually + referred by the pair (r, s). The signature value shall consist of the + concatenation of two octet-streams that respectively result from the + octet-encoding of the values r and s. Integer to octet-stream + conversion shall be done according to PKCS#1 [RFC 2437] specification + with a k parameter equals to 20. + + Example + + P.4 + + + P.5 + + + + +5.2.2 HMAC + + Message Authentication Code proposed by H. Krawczyk et al., and + documented in [RFC 2104]. + + This specification adopts a scheme that differs a bit from the common + usage of this algorithm -- computation of the MAC is performed on the + hash of the contents being authenticated instead of the actual + contents. Thence, the actual signature value output by the algorithm + might be depicted as follows: + + SignatureValue = HMAC( SecretKey, H(Manifest)) + + This specification also considered HMAC output truncation such as + proposed by Preneel and van Oorschot. In their paper [PV] these two + researchers have shown some analytical advantages of truncating the + output of hash-based MAC functions. Such output truncation is also + considered in the RFC document. + + + + +Davidson & Kawatsura Informational [Page 18] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + HMAC requires three parameters. The first one consists of a canonical + digest algorithm. The second one consists of a hash function. The + last one is optional and specifies the length in bit of the truncated + output. If this last parameter is absent, no truncation shall occur. + + The HMAC URN used in this specification is "urn:ietf-org:hmac". + + Canonical digest algorithm: Canonical or surface-string digest + algorithm is to be used for computation of the Manifest fingerprint. + The type of this parameter is set to "AlgorithmRef". The recommended + value of this Parameter should be the ID reference for the Algorithm + element DOM-HASH. + + Hash-function: Hash function is to be used to compute the MAC value + from the secret key and the fingerprint of the signature Manifest. + The type of this parameter is set to "HashAlgorithmRef" and the value + of this parameter should be set to the ID reference for the Algorithm + element of SHA1. + + Output-length: Length in bits of the truncated MAC value. The type of + this parameter is set to "KeyLength" and the value of this parameter + is set the length in bits of the truncated MAC value. + + Signature Value Encoding: + + The output of this algorithm can be assumed as a large integer value. + The signature value shall consist of the octet-encoded value of this + integer. Integer to octet-stream conversion shall be done according + to PKCS#1 [RFC 2437] specification with a k parameter equals to + ((Hlen +7) mod8), Mlen being the length in bits of the MAC value. + + Example + + P.4 + P.5 + 128 + + + P.5 + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 19] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +5.2.3 RSA + + Public-key signature algorithm proposed by RSA Laboratories and + documented in PKCS#1 [RFC 2437]. + + This specification adopts the RSA encryption algorithm with padding + block type 01. For computing the signature value, the signer shall + first digest the signature Manifest and then encrypt the resulting + digest with his private key. + + This signature algorithm requires a single parameter, which consists + of the canonical digest algorithm to be used for computing the + fingerprint of the signature Manifest. + + Specifications + + The RSA URN used in this specification is "urn:rsasdi-com:rsa- + encription". + + The RSA uses a canonical or surface-string digest algorithm for + computation of the Manifest fingerprint. The DOM-HASH is recommended + in this specification. + + Signature Value Encoding: + + The output of this algorithm consists of single octet-stream. No + further encoding is required. + + Example + + P.4 + + + P.5 + + + + +5.2.4 ECDSA + + Public-key signature algorithm proposed independently by Neil Koblitz + and Victor Miller. This algorithm is being proposed as an ANSI + standard and is documented in ANSI X9.62 standard proposal [X9.62] + and IEEE/P1363 standard draft proposal [IEEE P1363]. + + + + + + +Davidson & Kawatsura Informational [Page 20] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + The ECDSA algorithm requires a single parameter, which consists of + the canonical digest algorithm to be used for computing the + fingerprint of the signature Manifest. + + Specifications + + The ECDSA URN used in this specification is "urn:ansi-org:ecdsa". + + The ECDSA uses a canonical or surface-string digest algorithm for + computation of the Manifest fingerprint. The DOM-HASH [RFC 2803] is + recommended in this specification. + + Signature Value Encoding: + + The output of this algorithm consists of a pair of integers usually + referred by the pair (r, s). The signature value shall consist of the + concatenation of two octet-streams that respectively result from the + octet-encoding of the values r and s. Integer to octet-stream + conversion shall be done according to PKCS#1 [RFC 2437] specification + with a k parameter equals to 20. + + Example + + P.4 + + + P.5 + + + + +6. Examples + + The following is an example signed IOTP message: + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 21] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + + + + + + P.5 + + + P.3 + + + + + xsqsfasDys2h44u4ehJDe54he5j4dJYTJ + + + + + + + + 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0 + + + + + + xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= + + + + + + + snroasdfnas934k + + + +Davidson & Kawatsura Informational [Page 22] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + + + + + +7. Signature DTD + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 23] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 24] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + + + + + + + + + + +8. Security Considerations + + This entire document concerns the IOTP v1 protocol signature element + which is used for authentication. See the Security Considerations + section of [RFC 2801] "Internet Open Trading Protocol - IOTP, Version + 1.0". + + + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 25] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +References + + [DSA] Federal Information Processing Standards Publication + FIPS PUB 186, "Digital Signature Standard(DSS)", 1994, + + + [IEEE P1363] IEEE P1363, "Standard Specifications for Public-Key + Cryptography", Work in Progress, 1997, + + + [PV] Preneel, B. and P. van Oorschot, "Building fast MACs + from hash functions", Advances in Cryptology -- + CRYPTO'95 Proceedings, Lecture Notes in Computer + Science, Springer-Verlag Vol.963, 1995, pp. 1-14. + + [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC 2046] Freed N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC 2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [RFC 2253] Wahl, W., Kille, S. and T. Howes, "Lightweight Directory + Access Protocol (v3): UTF-8 String Representation of + Distinguished Names", RFC 2253, December 1997. + + [RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography + Specifications, Version 2.0", RFC 2437, October 1998. + + [RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP, + Version 1.0", RFC 2801, April 2000. + + [RFC 2803] Maruyama, H., Tamura, K. and N. Uramot, "Digest Values + for DOM (DOMHASH)", RFC 2803, April 2000. + + + +Davidson & Kawatsura Informational [Page 26] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + [Schneier] Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and + Sons + + [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National + Institute of Standards and Technology, U.S. Department + of Commerce, April 1995. + + [X.509] ITU-T Recommendation X.509 (1997 E), "Information + Technology - Open Systems Interconnection - The + Directory: Authentication Framework", June 1997. + + [X9.30] ASC X9 Secretariat: American Bankers Association, + "American National Standard for Financial Services - + Public Key Cryptography Using Irreversible Algorithms + for the Financial Services Industry - Part 1: The + Digital Signature Algorithm(DSA)", 1995. + + [X9.62] ASC X9 Secretariat: American Bankers + Association,"American National Standard for Financial + Services - Public Key Cryptography Using Irreversible + Algorithms for the Financial Services Industry - The + Elliptic Curve Digital Signature Algorithm (ECDSA)", + Work in Progress, 1997. + + [XLink] Eve Maler, Steve DeRose, "XML Linking Language (XLink)", + + + [XML] Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible + Markup Language (XML) 1.0", + + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 27] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +Authors' Addresses + + The authors of this document are: + + Kent M. Davidson + Differential, Inc. + 440 Clyde Ave. + Mountain View, CA 94043 USA + + EMail: kent@differential.com + + + Yoshiaki Kawatsura + Hitachi, Ltd. + 890-12 Kashimada Saiwai Kawasaki, + Kanagawa 2128567 Japan + + EMail: kawatura@bisd.hitachi.co.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 28] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 29] + -- cgit v1.2.3